Less Estimation, More Trust

22 Mar 2015. comments

A good deal of this article is based off of thoughts from Ernie Miller’s talk at Ruby on Ales 2015.

We’re in the business of producing software. If you produce software for products/services then you know that these businesses tend to value predictability, measureability, and control. The way most businesses try to obtain this predictability/measurability is by abstracting software developers to ‘resources’ and then using math derived from software estimation. This fails utterly, every time.

Software developers are not ‘resources’ in the same way that software managers are not ‘overhead’ and using those terms are offensive. Software developers and those who manage them are humans. And it turns out humans are messy. Software is messy too, because it’s abstract and built by humans.

There is a long standing tradition in this field of comparing software development to construction, like constructing a building. This was a reasonable place to start when software development was a new field since humans operate best with analogy and comparison to things they already know. But we quickly found out that building software is nothing like building buildings. Buildings are static and we’ve built a lot of them over hundreds of years. Software, on the other hand, is an organic, creative, moving target. Software is malleable. There are very few bits of software that are identical because the people and businesses for whom the software is being built are rarely similar, much less identical.

And the time you know the absolute least about the software you are going to be building is at the start.

“Writing software involves figuring out something in such incredibly precise detail that you can tell a computer how to do it.”

“If you were to write a specification in such detail that it would capture [all] those issues, you’d be writing the software itself.”

Dan Milstein, Coding Fast and Slow:


Given this organic nature of software, I believe long term estimates are lies. Giving these estimates means that you are saying:

  1. I understand everything about the problem.
  2. I know that my customer will absoloutely love the software I give them and will not want any changes.
  3. I know that the software constructed according to the plan will be the exact software we end up with at the end.
  4. I have built this exact thing before and therefor know the time it takes.

All of those are ludicrous and we shouldn’t kid ourselves by thinking otherwise. At best these estimates are useless; at worst they are malicious and destructive to the business who is planning based on them.

Software also never lives on its own. Every piece of software has dependencies on other software. That other software is just as organic, malleable, and creative as your software. The effect then is multiplicative. The uncertainty isn’t even contained to just your software.

The issues can be wide ranging:

  • The service you are integrating with doesn’t actually meet your needs but this isn’t discovered until down the road.
  • The library you are building on top of has a big bug. That bug is going to be addressed, but you don’t control the timeline of that fix.
  • There are unforseen network issues between you and a service. They arose during development.
  • The service you depend on decides to close shop.
  • The service you depend on decides to start charging you money instead of being free.
  • The customer realizes something about the software that couldn’t be realized until part of the software was written and a demo was given, revealing the issue. New dependencies are needed.
  • Etc, etc, etc.

So be a professional. Providing these estimates is just lying to ourselves and our stakeholders. Estimates also have a funny way of turning into deadlines. And because the organic nature of software development those deadlines quickly become out of touch and just as useless as the deadlines they were produced from. Deadlines emphasize the dates as being the important part and de-emphasize building the right software that will please the business and its customers.

So are all estimates hopeless? Maybe. Large software tasks have been proven to be uncertain/organic/malleable with uncertainty multipled by every dependency you integrate with. But what about small development tasks? Tasks that fit into less than a couple of days are usually estimated reasonably well or at least well enough to where it doesn’t matter if they are off by a bit. Tasks of this size also tend to be much more ‘regular’ than large scale development. And they have the advantage of being small enough to have a tight feedback loop that allows you to course-correct if they fell prey to the same issues outlined above.

But even if you estimate in this way you’ve really just brushed the real problem under the rug by making the failures of estimation less costly. What if instead we ignore estimation in service of some finish line and instead just worry about the next feature we need to deliver? Why not focus on delivering the Next Most Important Thing continuously at a sustainable pace? Maybe you do it weekly; demo working software to your customer at the end of every week? Working at these time scales allow the organic nature of software to be dealt with. Customer changes can be incorporated, dependency issues can be dealt with, course corrections can be made.

A big disconnect exists between developers and managers on these points. I think it stems from:

  • Software developers continuing to provide estimates.
  • Business continuing to pressure developers to provide those estimates.
  • Both believing that those estimates are meaningful.

It’s no wonder there is a divide between software management and software developers. Software developers regularly provide estimates and those estimates are very often off by an order of magnitude. This leads to a lack of trust. Why would you trust software developers when their estimates are so bad? The only way out is for us to stop doing this estimating dance. Stop committing to months-long deadlines. Start talking openly about the true nature of software development and commit to delivering value weekly.

The uncertainty about software development timelines needs to be put right out in the open. The factors that cause the inability to estimate with any kind of accuracy need to be put out in the open. These are issues that need to be on the table for the entire business to grapple with, not just software developers. Businesses need information to be successful and if that information is tied up in the Mysterious Land of Software Development then the business won’t know about the impending failure until it arrives and it’s too late. Developers who all-too-frequently crunch to meet these estimates/deadlines are doing a disservice to the business.

A true professional doesn’t change how he/she operates under pressure. Be honest about estimation and why it fails. Be honest about all the uncertainty factors that make up estimation woes. Work together to deliver valuable working software on a more frequent, less estimation focused basis.


Tagged: estimation agile software engineering software craftsmanship

2017 Ben Lakey

The words here do not reflect those of my employer.