Why estimating software is hard

One of the biggest misconceptions about software projects is that estimating them is a quick, simple task. When someone asks, "How much would this change cost?" they may imagine one person thinking for ten minutes and producing a number. It comes to mind someone calling over the phone to ask for the price of an item; on the other end, the person taking the call is looking at a catalog, finding the item number, and looking up the price.

In reality, a responsible estimate often requires multiple people and hours just to understand what needs to be built.

Behind that single number, there are conversations about design, engineering, integrations, data, testing, and edge cases. The number is the output of that thinking. An estimate is already work, which we don’t have any problem doing the first time, or even the second, but from then on it’s billable work.

I’m not saying we should charge for estimates, even if that's a great idea. Estimates are part of the cost of doing business, but there’s a reasonable limit that we all have to pay attention to. At the end of the day, we are running a healthy business, not trying hard to go bankrupt.

Reminds me of this client we used to have. Lots of ideas ended up in multiple proposals that went nowhere. One of them was a loyalty program. We worked hard on that one, multiple meetings, research, writing, designing, tweaking details to make it just right. After presenting, instead of seeing the value in what was already there, the focus was on what else they could add. I do believe the best designs are simple; complexity actually shows a lack of work.

We had this interface asking for three or four fields of customer information, simple enough to get what we needed without adding more work for the user, but for the client, it was too simple, so it started asking for more fields (why not?). We came back, worked on the changes, presented, and, again, those new fields gave them new ideas and more information they could ask for. Went back and redid the whole thing, just to present again and get more changes suggested. Adding just one more field forces changes across screens, validation, storage, integrations, notifications, rules, and testing. The point isn't that every change explodes into an impossible task. It's that complexity doesn't grow in proportion to what the client visually sees.

The fact that you open Google to see one field doesn’t mean the cost to get there was less than having many fields. It’s actually the complete opposite; simplicity requires more work to get it right.

Despite the good intentions of this client, we couldn’t take it anymore. We felt miserable doing all this work that they couldn’t appreciate. We just couldn't simply tweak the last estimate after each new request. Each change reopened earlier decisions, and we had to redo it all. That means the proposed solution changed, not just an item we could just copy and paste into the proposal.

A cohesive solution is like a puzzle; you change one piece, and nothing fits anymore. It’s an illusion that makes anyone think it's just gonna take a minute, when the reality is that it takes several people, several hours, and deep work before coming up with a budget is even possible.

Again, it’s not about charging for estimates; that’s the cost of doing business. It’s about the cost of certainty. The more precision someone wants, the more of the problem you have to solve up front. At some point, estimating becomes doing; therefore, it must be paid for.