Estimation is hard. It may not be listed as one of the top two problems in computer science, but it’s at least a close third. Over the years I’ve gotten to try all sorts of methodologies for estimating. Waterfall, Agile, Points, Stories, Requirements, Features, Epics, Pomodoros, Billable hours… you can go on forever with the Jargon of Management, trying to get information from a developer about how much longer The Client has to wait until The Feature is finished.
About 4 years ago I started a job where a coworker was an avid Rubik’s cube solver. I learned the steps and began competing with him to see who could solve a cube the fastest. Eventually, my top time ended up around a minute and thirty seconds. There are guys who can do it much faster–but I’m interested in consistency and improved speed. Sometimes I can solve very quickly because some steps can be skipped (i.e. they are done for you) or because I’m using a very good cube, but in general, I can solve a cube in 1:30 - 3:00.
But I don’t do it blindfolded.
The world record for the fastest solve is just under 10 seconds, but the world record for the fastest blindfold solve (i.e. from the time you pick it up, look it over, and then blindfold yourself to begin solving) is over a minute and a half–10 times as long. The reason is simple–feedback. Immediate and quick feedback allow you to take shortcuts and spend less time worrying about the next 200 moves and just worry about the next step or two.
So why do we still tend toward “blindfolded” approaches in software?
Waterfall vs. a Feedback loop
Call it Agile, call it scrum, call it feedback–it doesn’t matter. What makes a team think they’re going to deliver better because they took the time to figure out all the steps, when you don’t know exactly how one step will affect the next? It’s foolish when you consider it, but still, so many teams do it. Even the supposed “agile” teams end up blindfolding releases and then trying to ‘feedback’ the sprints. That’s not to say there should be no planning, but getting customer and developer feedback is crucial to accurate and fast solutions to problems.
What should we be doing instead? In Rubik’s Cube solutions, you typically identify the next ‘step’ and iterate over it, examining the result and deciding the following step at that point. You might be able to ‘blindfold’ for each step, but you’d still need to look at the end to figure out where to go next. I think a similar paradigm works in software building. Identify the key feature, and let the developer work on it, deploy it, and get feedback. Iterate on it again if it’s not quite right. If it is, then move along to the next step or feature.
Where does this analogy break down? Architectural changes. You can’t make sweeping changes underneath the system without a good deal of planning and “blindfolding” where you step through, unsure of the effect on the system because you can’t actually evaluate it. There are times this must occur–but as developers, we probably tend toward a desire to rearchitect more often than we should. Always consider what the right solution is and evaluate the cost of technical debt vs. the potential cost of an underlying change that could have pervasive and unknown effects. Sometimes it is necessary, but generally it’s not. YAGNI is your friend.
The tighter the feedback loop, the more accurate and more quickly you’re able to deliver a solution, whether in Rubik’s world or in the Software space. Focus on tight loops with customer feedback and developer feedback and watch your estimation troubles diminish.