Software estimation is hard – do it anyway

Billing a customer for a feature they want. How much you charge the customer is going to depend on how many dev hours it will take. An accurate estimate is necessary in order to give come up with the appropriate price to charge them. Name a price that's too low, and you end up losing money on devs' salaries. Name a price too high and the customer walks away from the table

I'd like to see the author's quantified track record of giving accurate estimates before I take their advice.

In my experience, software project estimation is the thing that everyone thinks someone else must be able to do well, and that they could do it if only they had more discipline. Then we get the tired old advice about breaking the project up into smaller chunks. But all the studies I've read of actual estimation methodologies show something like 300-600% error rate.

People think this must be doable because they want it to work, and they want an estimate. It's the same way that people thought one witch doctor was better at curing disease than another, when in reality none of it really does what's claimed.

I'm convinced that elaborating the spec in enough detail is the work of software engineering, and once you've done that fully you've done the whole project.

A lot of the comments here paint a picture of a dysfunctional relationship with business stakeholders, and then suggest defensive techniques to cover your own ass. I understand why one would need to do this in certain situations, but I would also say that your impact and skill growth will inherently be limited in these situations because you're lacking the fundamental thing that cross-functional teams need to succeed: trust.

The bottom line is this: exact estimates, especially for large projects are a crapshoot. There is often more than one way to solve a business problem, and long-lived consequences for maintenance, operations and future development. The best solution to large problems can not be arrived at by simply throwing an ill-conceived one-liner prescribed solution over the wall to an engineering team and say "estimate this". What works is to bring a small group of highly skilled practitioners and business operators who have the capability and experience to zoom in and out of the problem space enough to shape a sane low-fidelity plan, and then commission the right discovery and validation to formulate a full plan. This does depend on having the right people in the room and mutual trust between them. It's very easy for one bad apple to derail this whole thing either through outright incompetence or else inability to listen and understand another point of view. Often on HN we paint the picture of the clueless pointy-haired boss making bad decisions, but equally as damaging is the arrogant engineer who is unable to see past their own biases to play out potential tradeoffs with other areas that they don't have deep expertise in.

In my experience there are three things that often get conflated around software estimates:

   1 Effort versus calendar time.

   2 Estimate versus commitment.

   3 Confidence level - are we talking P50? P99? P100 under some set of assumptions?

I don't think I've ever worked in a setting where everyone shared the same understanding on all of these points.

Paid overtime will fix scheduling. Scheduling is bad because the cost falls on the employees, not the employer. If crunches resulted in time and a half, double time, and triple time, scheduling would get fixed.

As I've pointed out before, film scheduling is an established discipline. Making a movie is much more complex than a software project. There are a lot of moving parts. Things get changed. There are people problems, weather problems, and transportation problems. Most importantly, if a film project goes into crunch mode, everybody starts getting paid overtime. This reduces the tendency to underestimate.

There are also third party estimates. Hollywood has something called "completion bonds". A completion bond is an insurance policy for the investors. Either they get a showable movie into theaters, or the completion bond company has to pay the investors. A completion bond costs about 5% of the cost of the film.

Completion bond companies do their own estimates. Estimation inputs are "script, budget, shooting schedule, (and) résumés of key crew." To survive, they need a net error near zero - they must overestimate and underestimate about equally. Consistent underestimation would put them out of business.

Since they do a lot of this, they have scripts and financial data from previous movies. They can look up "car chase, metropolitan area, 2 minutes screen time" for how much that cost the last 50 times someone did it. They also have director info, like "director X averages 2.5 takes per scene". All this info is collected across multiple film companies.

The completion bond company has the right to intervene if the project starts to go over budget. Worst case, they can fire the director and take over the production. This is rare, but it happens. "Malcolm X" by Spike Lee (1992) and "Bad Girls" are examples. "Malcolm X" was an epic movie, a bit too epic - it runs 3 hours and 22 minutes - and somebody had to say no to Spike Lee. "Bad Girls" (1994) was just a botched production, and the bond company put in their own director to try to salvage something. It still lost money, but did reach theaters.

That a completion bond company can fire the director puts teeth in this system.