The Art and Science of Software Estimation - Part 2: The Nature of Software
This is a four part article; I’ve divided this article into smaller ~4 min posts to make easier to read and follow up:
- Part 1: Anthropology of Time Estimates
- Part 2: The Nature of Software
- Part 3: Yin & Yang
- Part 4: Estimating Software
In Part 1: Anthropology of Time Estimates we examined how we humans measure values, assess our own competence and experience time.
In this post we have a look at why software estimation is hard and why most of our anthropological observations apply to software estimations.
The Nature of Software
Its Hard!
But what does all of that have to do with Software? Let me start by stating a fact; Software development is HARD.
Yes its a cliché, but if you’ve had any experience building software, you will probably agree with the statement; there are a lot of unknowns when it comes to software, mostly the human factor is responsible for 90% of those unknowns.
We build software for other humans that we have no control over how they’d interact with it, not to mention that our software has to account for the physical world from time to time (Mechanical failures, natural disasters, political turmoil,… etc.).
Take for example dating (No not that kind of dating 😉), modelling dates and time in software is hard; there are many calendars and methods to measure time that vary in use according to cultures and countries, and from time to time you need to deal with changes such as retiring day-light savings -If you’ve been around for more than 25~30 years, you might also remember Y2K and the worries of cyber apocalypse on the day of the new millinea-.
Software too follows Murphy’s Law, it needs constant maintenance and enhancement to keep working correctly and efficiently.
That factor of uncertainty and obscurity makes software development hard, and is the reason we have techniques like Defensive Programming and Chaos Programming.
Mostly new?
One could argue that even though Software Development is hard, our cumulative experience building software eventually makes it predictable and thus measurable, but that’s only true if technology slows down.
As technology advances, our expectations of what can be done with software grows, and we are faced with newer and harder challenges that we have no idea what kind of effort is needed to overcome.
Think of the pyramids, at the time of their building it was the pinnacle of engineering, and many would falsely assume that the first pyramid was perfectly built on the first trial, but in fact it took the Pharaohs several trials at smaller less perfect pyramids before they could build the first one, but then what? Expectations grew; each Pharaoh wanted to build a bigger and stronger pyramid than their predecessor, and fast forward today, we are still competing at building the tallest skyscraper or the longest bridge, and every time our ambitions grow, we hit new challenges that were previously unknown to us.
Same with software, just as the expectations of Pharaohs increased and their aspirations grew with every technological advancement, so does our present expectations grow with every new technological discovery, this makes software an ever changing plane where we constantly face challenges we’ve never had experience overcoming before.
Conclusion
Software development definitely qualifies as a hard activity to take lightly when estimating, its full of unknown challenges and variables that easily overwhelms our assumptions and predictions.
In Part 3: Yin & Yang we take a look at the nature of projects and deadlines, and how we can approach them in a practical and scientific way.