The Most Pointless Exercise in Software Development!

Photo by Michael Fousert @michaelfousert on Unsplash

I’m going to call it. I’m going to identify the most pointless exercise in software development. I don’t consider it to be the creation of JIRA tickets. I don’t think that it’s back to back meetings. I don’t even think it’s battling with a poor quality IDE.

So, what is it? In my humble opinion it’s estimating an estimate. Utter nonsense and a masterclass in wasting time.

Why Would We Estimate An Estimate?

It’s happened to me multiple times across companies, and the most recent instance has literally been this week.

I’m sitting innocently in a planning meeting, hoping that there will be an interesting ticket tossed my way to break me out of my slumber. Someone suggests a spike for a slightly more challenging piece of work and generally I’m grateful for the opportunity to be able to look at something rather than being asked for an immediate answer. It takes a mature team to accept that we don’t know something, and I’m appreciative that we will take the time to figure out our approach before committing to work.

Then, the inevitable happens.

“How long will the spike take?”

I keep working in places where story points map directly to time (I know! But that’s not a reason to quit a job, now is it?). So effectively I’m being asked to estimate the time it will take to come up with an estimate.

Let’s pause and really think about what’s happening here.

1. We’re acknowledging that we don’t have enough information to estimate the actual work.

2. To gain that information, we need to do a spike.

3. But before you do that research, I need to provide an estimate on how long the research will take.

4. The outcome of that research is… an estimate.

I’m now estimating an estimate. If I knew how long the spike would take then I would also know how long the work would take, negating the need for the spike. In multiple meetings I’ve failed to make the idiocy of my task truly clear.

Estimations? I don’t know how long they will last

Estimating is flawed anyway. I’ve previously worked in a team where every member would insist on giving themselves a contingency time for every ticket they had on their plate. I don’t exactly blame them, they acted logically in a flawed process where people are penalised for not finishing tickets on time, and punished if their estimate is too demanding.

So, when you estimate a feature, at least you have some information, past experience, similar tasks, maybe some gut feeling you do your best and if you get it a little wrong sometimes typically nobody minds as long as you aren’t too long, too often. Now when you estimate a spike, you’re literally guessing how long it takes to guess something with the same issue that you can’t afford to take too long. 

Since you’re being asked the equivalent of “How long will it take you to find out how long it will take to land on Mars?” you leave as much contingency as you think you can get away with. It means the project suffers as a result, and ultimately things are delayed over time.

The Agile Theater

Agile theatre is a game we play that means we pretend software development is predictable, neatly scheduled, and free from unknowns. It’s a fantasyland where velocity must be maintained, and every sprint must be planned to the hour, despite the entire industry being built on exploration and uncertainty.

Management loves predictability. Agile coaches love burn-down charts. But software development isn’t manufacturing, it’s a series of unknowns, experiments, and educated guesses. The more we pretend otherwise, the more we force developers into this absurd cycle of estimation about estimation.

Yet we are pushed into this nonsense by our teams, and we need to go along with this to keep the peace — and ultimately keep our jobs.

The Solution? Just Stop

Here’s my radical idea. Stop estimating spikes. By inference, start trusting your developers.

Instead, set a purpose for the spike:

What do we need to learn?

What questions do we need to answer?

What are the possible paths forward?

Give the team the time to figure those things out. Then, and only then, should we even think about estimating actual work.

Estimating a spike only gives a false sense of control. It’s corporate games at its worst, we might do something completely meaningless but let us carry on regardless. If you’re forcing estimates on spikes, you’re setting up your team for failure before they even start. Worse, if you’re a developer and don’t raise this in your retro you are complicit in the failure of your team.

Final Thought

If you ever find yourself in a meeting where someone asks, “How long will the spike take?” take a deep breath before responding. Then (as powerfully as you can muster) say this:

“How long will it take you to tell me how long it will take you to tell me how long it will take?”

Then sit back and watch the Agile Theater burn down.