I came across an interesting question on Quora which asked about why software development task estimations are regularly off by a factor of 2-3.  The question goes on to ask if it’s the developer’s fault, a management issue, bad methodology or lack of methodology or if it’s ingrained in the nature of the process.

There are some very interesting answers on Quora but the best answer may have been described by Michael Wolfe, a startup founder.  He explained that software development is like hiking from San Francisco to Los Angeles and estimate that you’ll reach your destination in 10 days.  It starts with you plotting your coordinates on the map and discover that it’s a 400 mile long hike.  If people walked 4 miles per hour for 10 hours a day, you’d reach your destination in 10 days.  But as you make your way, you’ll discover a lot of obstacles such as rocky terrains, winding stairs, blisters on foot, bad weather and others that would make your trip longer which will make your friends in Los Angeles pretty pissed off since you’d be calling often to inform them that you have to push back the date of your arrival because of said obstacles.  Then if you’re travelling in a group, you can’t expect everyone will be as determined as you to reach your goal because you’re the one who presented the timeline to your waiting friends, in short, it’s your neck that’s on the line.

Other answers aren’t as creative as Wolfe’s but they make sense just as much.

Revett Eldred, a grey haired aging geek, explains that you can’t just come up with an idea and expect that everything will go as you imagined.

“[I]t pays to spend way more time analyzing the issue and specifying the functionality of the system than most people do.  Fixing those problems is what takes extra time and blows the schedule.  Even with totally different programming fundamentals and languages today, and with the widespread reuse of code, that rule still applies,” Eldred says.

He also stated that he learned two things in building a successful application development business:

1.  Never commit to a fixed schedule for the whole project.  Commit to a fixed schedule (and price) for the specification phase, and when that is complete commit to a fixed schedule/price for the design phase, and when that is complete commit to a fixed schedule/price for the implementation phase.

2.  Build in to your contract the world’s most comprehensive change control rules and procedures, and apply them rigorously.

Arun Shroff, an entrepreneur, presents four reasons as to why software development task estimations are regularly off.

1. The Mythical Man-Month and Brook’s Law

Based on the book written by Fred Brooks who managed the development of IBM’s mainframe operating system OS/360, it states that not because more people are working on a project means that it will be completed faster, especially if you’re adding manpower late in the game.

“Adding manpower to a late software project makes it later. A man-month is a concept of a unit of work proportional to the number of people working multiplied by the time that they work; Brooks’s law says that this relation is a myth, and is hence the centerpiece of the book,” Shroff explained.

2. The tendency towards irreducible number of errors

Shroff explains that when you discover and try to fix an error, there’s a huge chance that you’ll encounter more errors along the way.  He explains that this is very hard to predict and could cause insurmountable delays.

3. Feature creep, creeping featurism or featuritis

Explained as the ongoing expansion or addition of new features in a product.  When you start out a project you have a clear goal in mind – get from point A to B without any delays.  But as you work on it, you or your team may think of how to make the project better, you add more things.  By adding things, this will no matter how minute they are, would require time and testing to make sure it will work as smoothly as planned.

4. Accidental complexity

Explained as a complexity that “arises in computer programs or their development process which is non-essential to the problem to be solved. While essential complexity is inherent and unavoidable, accidental complexity is caused by the approach chosen to solve the problem.”

What about you?  What do you think causes delays in software development or what causes them to miss estimations?