Software estimation is hard – do it anyway

Seems like there's a hint of survivorship bias. The author will eventually give a bad estimate. There's no secret or trick otherwise it would be widely known by now.

Even the video games industry has been coming around on this in the last decade. This is a sector of the software industry famous for making aggressive, impossible deadlines for itself. It has ruined countless lives trying to hold to them. The smart ones talk about milestones and road maps. They don't announce release dates until they're basically done and ready to cut the release.

This is the conclusion you come to after you churn staff year after year and people leave in droves and never come back.

An aggressive sales team can ruin a small company. If what they sell is a deadline and promises they can't keep your team has no control or autonomy. People feel good when they have autonomy over their work and feel in control. They get burned out when their company/career is on the line when an estimate they were forced to make blows past due to forces outside their control.

I always recommend selling on what you can control. Promise only what you can deliver: your skills, experience, and knowledge. You can try to estimate how long it will take you but you will be wrong 66% of the time. The people in those studies were also as smart, or smarter, than you. There is no secret.

Software is trivially copy-able, and as such large software projects are unique enough that accurately estimating them is impossible. This is in contrast to something like building a house. I build a single house, figure out how much that cost and now have a very good reference point for how much building that same house over and over will be.

I really like the approach that Basecamp recommend in Shape Up[1] where the team pivots to reasoning about work in terms of appetitie rather than expected time.

[1] https://basecamp.com/shapeup/1.2-chapter-03#setting-the-appe...

There are lots of reasons for that, which can fall outside of the scope of engineering, but the same is true for software.

However, in the end, code is just a very detailed specification of the design that produces a desired outcome. There's a reason why production is called production, after all:

https://www.commitstrip.com/en/2016/08/25/a-very-comprehensi...

Therefore, equating code written by a software developer with the final result is a little like equating an architect's blueprint with a building that was built according to that blueprint. The fundamental difference between those disciplines, of course, is that with software development most of the manual (as in: non-automated) work is done once the code has been written, whereas with construction the by far largest part of the manual work involved happens after the architect has created the blueprint.

On one hand, this is a problem of perception. On the other hand, though, it's quite understandable that customers don't want to invest the better part of the budget upfront, not knowing if the design will meet the requirements.

This is where agile management methods come into play. Those can be misused or, indeed, abused, too, but the idea of eliminating waste and adapting early is a sound one.

Then when it turns out estimates are out, I'm stuck in another meeting where they melt down about how they're going to explain overruns to their bosses. Utterly predictable madness.

Then they had the nerve to get arsey when we started refusing to estimate.