What’s the hardest problem in software development?

Estimation. That’s it. I must’ve said this at least 100 times to people all over the industry and not once have I gotten an argument. I mean, techies love to debate, and I’ve never gotten as much as a “Yeah, but…” There’s no “but” – it’s unanimous. But why, oh why, is this so hard?!

Because it’s never been done before.

You did the build versus buy analysis and picked build. You’re not installing off the shelf software that solves all your problems. Even if you are buying something, it needs to be heavily customized to your unique needs.

The act of creation is highly unpredictable.

Heck, how many times have kitchens been remodeled, yet yours still took longer and/or cost more than they quoted? Software is no different. In his excellent book Facts and Fallacies of Software Engineering, Robert Glass said estimates are wrong because:

  • They’re done at the wrong time: at the project start when you have the least information.
  • They’re done by the wrong people: often managers and marketers, not the developers who will do the work.
  • They’re never revised as new information comes in.
  • Even if they are revised, project success or failure is judged by the initial estimates/schedule.

In my experience, there are two that come up more than others. The first is remembering only the first estimate, even after it has been updated continually. “When this project first started, they said it would take three months! It’s been nine!” It doesn’t matter that 2 months in, they communicated that a serious challenge (and certainly scope creep) has turned this into a one-year project. They just see their bank balance shrinking every week and their blood pressure going up.

The second is confusing a deadline with an estimate. “You said you’d have it done by the 15th, but this feature is still missing!” No, marketing said it had to be done by the 15th, and engineering said they would need more engineers and were denied. Or there simply wasn’t enough time to hire someone and get them trained on your system. Or management thought working everyone extra hours would solve it.

Tell me, what have you seen?