Why Don’t Developers Like to Estimate Time Accurately?
I was reading this just now – Why Can’t Developers Estimate Time? – and realized the discussion leaves out some fairly important psychological factors that influence time estimates significantly.
As the developer, you focus on the risky bits — the parts that are technically difficult & complex, that use new APIs or new libraries you aren’t familiar with, that require designing a new UI, or matching very strict performance tolerances.
For these sections, developers (with a little training) can learn how to estimate as well as possible — it’s hard, we know it’s hard, and either we’ll say “that’ll take a long time” or we say “we’d better do a proof-of-concept first, because I’m not sure at all how that will go.”
Now we get to the rest of it — the trivial parts. Writing some simple tests, taking input, validating it, storing it, returning something else simple straight out of the database… it’s simple, it’s boring, and any developer on the team could do it.
But it always takes an embarrassingly long time (with the emphasis on “embarrassing”).
And it takes a long time because of trivial little things going awry; random little errors falling into blind spots; naming and organizational trickiness; various forgotten tasks (also trivial, but also time-consuming); odd little snags that turn up. The developers will get through them — that’s not in question — but there’s no looming dangerous issue they can defeat proudly. Regardless, the time has melted away.
This happens even with tasks where we’ve done this before. And to be sure, there’s quite a lot of software development that falls largely into this category.
So for a more well-rounded approach to the problems of estimating: definitely, work on defining “done”, measure as well as possible, break things into small units of work, etc., but also try to minimize the psychological factors pushing in the wrong direction (more on that below).
Paying (and dodging) the boring tax
Besides the factor I mentioned above — the embarrassment skew — there’s also what I think of as the “boring tax” — anytime you’re working on something uninteresting, it’s going to take longer simply because it’s boring. As a developer, you won’t be attempting the impossible and pursuing glory and accolades with a laser-like focus… you’ll be trudging along, and if you hop over to StackOverflow to double-check some minor technical detail, it’s pretty likely you’ll also take “just a second” to read about a much more interesting related question. You’ll wonder about other languages, frameworks, libraries, etc. that would be less boring to use for these boring tasks. You’ll think about doing some major refactoring to the entire section of the project you’re working on.
And because you’re already convinced that this is trivial (influenced by the embarrassment skew…) and you can blow through the remainder when you need to, it’s easier to give yourself permission to waste a bit more time along the way. Until the deadline is tomorrow, and the forgotten tasks pop their heads up, and you make a little mistake that causes everything to break in a really odd way.
This boring tax is easier to fight, though, and fixing that one helps to paper over the embarrassment skew as well.
DO NOT just add a percentage on to any estimate labelled “boring tax”.
That just moves out the date when the developer will realize it’s time to buckle down and get the boring stuff done.
Instead (with variations based on individual developer preferences/personalities, of course):
- recognize that developers really dislike “the boring parts”, for very valid reasons
- and that these tasks take longer than it seems they should, and that this is normal but unpleasant for the developer as well, so
- help motivate them — break up boring work into many small bits (so you have lots of little deadlines — this also helps tease out some of the forgotten tasks involved), so that they can (and expect to) accomplish multiple tasks in a day
- encourage pomodoro-style techniques to keep progress moving
- line up something more interesting for the next assignment. 🙂