Avoiding completely failed estimates

The relatively short post My Washing Machine Refreshed My Thinking on Software Effort Estimation by Chris Horsley (Cosive) is kind of interesting, in that it’s a cautionary tale about being overconfident about your estimates. As the title suggests, his was a real-world task where he’d assumed that a tenth iteration would go just as smoothly. He draws some good conclusions but for what I think might be the wrong reasons.

“[…] while 90% of the project will be the same, there’s going to be one critical difference between the last 5 projects and this project that seemed trivial at the time of estimation but will throw off our whole schedule. It could be one or all of:”

1. Our well-used task-running framework we were going to use for a relatively small part of the system is totally unmaintained now and we’d have to fork it to make it fit for purpose again.
2. Our entire development tooling ecosystem was obsoleted 18 months after the last time we did this, so we’re going to be learning the sharp edges of a whole new toolchain from scratch.
3. We find that our OS version has moved on and no longer supports key requirements for our existing dependencies, requiring rethinking or developing from scratch.
4. We need our infrastructure stack to use one component we’ve never used before and it doesn’t work anything like we expected.

The things that he lists as stuff that you generally don’t think about are exactly the kinds of things that you should keep in mind when doing an estimate, though! Like, if you’ve been doing estimates and any of these things are a surprise to you, then you’ve just been LARPing at estimates.

Even when you copy/paste an existing solution to a similar problem, you have to consider the context in which the original was developed and the degree to which that context might be different this time around. It’s not easy but it’s your job to be aware of limitations and concessions at all times. Always consider that the passage of time is part of the context.

It too so long to set up his washing machine because he’s a rank amateur at doing that, despite having done it so many times. He got lucky the first nine times because literally nothing that could go wrong went wrong. He thought that his experience promoted him to a senior-level position but he was still a junior-level monteur. On his tenth time, everything went wrong and he was totally blindsided by it—but only because he’d learned nothing about the system he was working on.

He didn’t learn, for example, what his requirements or environmental expectations were nor that he should quickly check to verify that they were satisfied before he started.

It’s as if he’d gone downstairs to check his car’s oil but hadn’t brought his house keys with him because the door to the garage had always been propped before. When he had to go back upstairs to get his house keys, that was considered a blindsiding showstopper that you couldn’t have accounted for.

Even after the first setback, he didn’t sit back to take stock of the situation and plan his next few steps rather than just his next step. That’s the classic misinterpretation of agile: it doesn’t mean you should turn your brain off in planning. It doesn’t mean you shouldn’t do any long-term planning. It means that you should always be prepared to change your plan. It means that you should take a little time to plan for the immediately foreseeable work. That doesn’t mean that you’re suddenly doing waterfall! It means you’re filling your backlog.