Half the Estimate, Double the Burnout
Photo by Sydney Latham on Unsplash
I’ve often railed against estimates. They often don’t make sense as a product manager asks “how long will this take” and you’re supposed to tell them so they can “plan a launch”.
I’m only joking. They’ll tell you that you need to make an estimate, and then they’ll ask you if you can do a hundred other things in parallel to get everything to work for their pre-planned “landing date”. Your “estimate” turns out to be a way to get your buy-in for the work that you’re going to do (fast) anyway.
Nobody would say that, would they. No. Except at our place.
“Take your estimate and halve it”
Sane companies don’t say this. The thinking is that developers always overestimate, and halving it will make everyone scramble to work faster and we’ll be able to get things done faster and better than our competitors.
Making a skinny estimate doesn’t do any damage. It just means we go faster and create a much better product than anyone else.
Right?
Right????
Wrong
Even if you got the estimate right with the data you have at any given time, there is huge variance in your work. You know why. The work is
Something we’ve never done before
Ill-defined requirements
Something Rob worked on before, so it’s a mess
Laden with dependencies that we don’t control
And somehow, we’re expected to give a precise number. It’s absurd. Then a clever representative of the business will tell us to halve the estimate.
Uncertainty turned into an absolute fantasy. The problem is that it is then turned into a muddys hit show.
Casualties
I’m completely against the artificial compression of timelines. It means developers often claim that work takes longer than it should, which is where the “developers are lazy” stereotype (partially) comes from.
I don’t like that, and once I did work with a senior dev who said that they padded their estimates by 50% “in case something went wrong”. Awful, and an awful individual to work with.
Yet it isn’t that type of developer who suffers from the estimate haircut. The casualties are the classics.
Refactoring
Architecture
Working through tech debt
Developer health (mental and physical)
Without these software quickly become unsustainable.
We are expected to add value in our jobs. Yet we are given the whip hand and told that we must deliver, and we need to deliver faster.
Eventually you get the question. The real question.
“Why is everything so slow to change?”
Optimising for speed now is going to have some impact in the future. You know that it’s true, right?
You put extra miles on the codebase, and eventually the tyres are going to run out of air. Worse, the same happens to developers and their fleshy human bodies.
We need to make the difference. It comes from
Working longer hours
Cutting corners
Carrying stress
Performance tanks when developers fail to get enough rest. Performance drops, decision-making worsens, and mistakes increase.
But who cares when we have a feature to ship?
Conclusion
They’re really saying they following
“We don’t trust engineering estimates”
“We’re optimizing for speed over accuracy”
“We expect you to absorb the gap”
They’re so close to saying these directly that it’s almost frightening.
But I kind of wish that they did, because then I’d know what to do. Yet I know what to do anyway.
About The Author
Professional Software Developer “The Secret Developer” can be found on Twitter @TheSDeveloper and regularly publishes articles through Medium.com
The Secret Developer took twice as long writing this article than they thought it would take. That’s an issue.