Why Software Development Estimations Are Regularly Off
- Edit
- Delete
- Tags
- Autopost
Some people believe that carrying out a large software project is like building a bridge. You look at your past projects and use the data to estimate the time and resources needed. This view has been debunked decades ago; this analogy was frequently seen as an aspiration for the future when I did my Master in Software Engineering at Carnegie Mellon in the late nineties.
In reality, most projects worth doing are not repetitions of previous things. If you need a bridge, you gem install bridge or extend bridge4j. A new software project is more like this:
- You are an inventor. You've invented a solar-powered microwave oven, an engine that runs on dead bugs, and a laser-powered weapon to kill mosquitoes. Someone comes to you and says:
"Hey inventor, I need a drone that will pick up mice (but not other animals), locate my ex-girlfriend and drop them on her head. Give me a budget and a time estimate."
Obviously you have no idea where to start. You need to understand the problem. This hasn't been done before, but it's not all new technology. Drones exist, location technology exists too. How about reliably identifying mice? How much do you really need to invent? Can you buy a DIY drone and modify it enough? Can the client slip a tracking device into his ex-girlfriend's purse?
Software is not about repeating, it's about inventing. This colorful post on Quora that's been making the rounds on Twitter is completely off the mark. The analogy of hikers going from San Francisco to L.A. doesn't apply. Long journeys by foot are something people have done for millennia, and all the knowledge you need is one Google search away. A luddite hiker will do the journey once and learn. When asked to hike between New York and Chicago, he will be much more accurate. After a few inter-city hikes he'll know enough to produce decent estimates. If I asked you to tell me how long it will take to drive from LA to SF, your estimate may be off by a couple of hours depending on traffic.
On the other hand, an experienced software engineer asked to build a control system for a car to drive itself from SF to LA is facing a completely different problem. Real software development is about doing something that you've never done before. That's why all stupid analogies about routine real-life stuff break.