I recently read Jacob Kaplan-Moss’ article Software Estimation Is Hard. Do It Anyway. His argument is that although estimation is hard, there are benefits to getting better at it and being able to provide accurate estimates. I disagree with his argument and propose a more helpful mindset.

Stop focusing on estimation

First, I take a stance against the title of the article. I don’t think estimation is hard. It is inaccurate. Perceptions change when we view estimation not as a difficult task, but an inaccurate task. Difficult tasks require smarter, more experienced people to solve them. Inaccurate tasks require people to reevaluate expectations and plan accordingly.

Kaplan-Moss speaks quite well of no-estimation techniques. His only argument against no-estimation is that it can’t answer the question “when will this be done?”

”However, sooner or later, someone’s going to ask “when will Feature X ship?” There are situations where having an answer – an accurate one – is non-negotiable. Maybe Sales can close a major deal if they commit to a timeline for some new feature. Maybe the feature in question is a major dependency for some other team, and they need to know how to schedule their work. Maybe your feature is one of many that will come together into a new product launch, and the whole product launch apparatus needs to spin up and promote it, which requires a timeline”

In his argument, uncertainty is the sole responsibility of the developer. The marketing team, the sales teams, and other engineering teams are allowed to live in a world of certainty. Only the developer being asked to estimate and do the work has to deal with the uncertainty inherent in software development. I don’t mean to unload responsibility onto other teams, but within a software company, every department is bound to the same level of uncertainty. The marketing team needs to anticipate delays. The sales and customer services teams need to handle incoming features asynchronously. All engineering teams need to respond to the same uncertainty, whether they are building on top of others work or not. Why are their deadlines non-negotiable?

”And it is a skill: estimation can be learned. You can learn techniques, but to some degree, they don’t matter: whatever technique you use, practice makes perfect.”

I agree that estimation can get better with practice. But I don’t believe anyone is good enough at estimation to earn the title of a reliable predictor. Kaplan-Moss describes good estimates only in terms of accuracy. This is the view of most proponents of estimation and estimation practice, but it overlooks a critical factor. Nine accurate estimations and one wildly inaccurate estimate is worse than ten somewhat-accurate estimates. That one wildly-inaccurate estimate can still delay an entire project. It is the variability of accuracy that decides the quality of an estimator. Developers can improve the average accuracy of their estimations, but no amount of practice will help estimating those tasks that contain unknown-unknowns.

“you can review those estimates against reality and recalibrate. Do this repeatedly and you’ll get better.”

Again, I agree that an estimator can get better. But at some point everyone reaches a situation where they’ll only get better as the work becomes more predictable. If your work is so predictable that you can accurately estimate it, then you are working on the wrong thing. You need to document your workflow and delegate that task to someone more junior, create an automated tool to do this for you, or hire an outside company to do the tasks.

You may disagree with everything I’ve said here. You’ve practiced and gotten better at estimating tasks. But you are no closer to knowing when work will get done. Imagine a task that only takes 30 minutes of your time, but at the half-way point you need to get further information from another team half-way around the world. So you won’t finish the task until tomorrow. Let’s even say you know this delay ahead of time. How do you estimate this work? Half an hour or a day? Most teams I’ve worked on would estimate this task as half an hour. But the person waiting on you to finish won’t receive your work until tomorrow. It would also be silly to estimate this work as a whole day. That would imply you wouldn’t get anything else done today, which is unhelpful to the teams waiting on your other work. Either way you are short-changing one of the teams depending on your work.

Focus instead on adaptability

Good software developers are not necessarily good estimators. I could share my own “oh yeah, that’ll only take a couple of days” stories. I have had tasks that were so routine that I knew they would only take an hour. Yet when I got started I found new uncertainties since my last time performing these same tasks: new tools, new outside vendors, new co-workers. Those tasks ended up taking an entire sprint.

If a sales or marketing or advertising team experienced a delay from a software developer, which in turn caused delays on their own deliverables, would blaming the developer be a valid excuse? Are they absolved of responsibility for their own work? I understand that many sales, marketing, and business people come from industries in which the product comes off of an assembly line or shows up on a flatbed truck. But working in a software business requires a change of mindset for everyone. Software developers are already experts at dealing with uncertainty and staying productive in the face of asynchronicity. Ask them for guidance.

So what does advance someone’s technical career? The most technically-advanced developers are those who can see progress changes on the horizon and communicate them quickly. If a project is getting stuck, or moving faster than anticipated, they inform all parties right away. They are good disseminators of status to the right people, at the right time, in the shortest format possible. They are good at relaying bad news, instead of feeling guilty and sitting on the information until it is too late to do anything about it. Good developers are adaptable. They are great at responding to new unforeseen challenges both technical and scheduling. They are experts in guiding entire teams in new directions as priorities and plans change.

I am regularly frustrated by people trying to make estimation better, despite evidence of its inaccuracy. Concentrating on estimation takes focus away from deeper questions: How can we make our process flatter, more parallel? How can teams be more independent? Is our company’s success really based on delivering this feature two weeks before a competitor? If we agree to products before they are finished, are we being honest with our customers? Does committing people to deadlines make them better/happier workers? What if something besides developer speed causes delays in delivering our product? The solution-space outside the estimation box is huge. We need to be looking there for answers to deliver better software more quickly.