Planning for failure
12 Jun 2009
Reading The planning fallacy over on Signal vs. Noise, I was struck at how off it seemed. The original article referenced was Planning for Fallacy and I think they all missed the point.
It’s all about planning for failure rather than planning for success. As a software engineer, you’re always considering the worst case runtime and space analysis. Linear search is always Θ(1) in the best case. If that always held true, why would we even bother improving on search?
When engineers need to give an estimate, they need to give the worst case. Always. Overly optimistic scheduling is a classic mistake that causes projects to slip (pointed out well in Rapid Development). These mistakes compound in large or complex projects because of dependent or related tasks.
One helpful technique I’ve found to keep these estimates better is by group estimation. This is commonly used in Scrum during Sprint Planning. Also, if you’re following iterative development, your iterations are short, so your dependancies should be small (or at least if things fail, they can only back up so much).
So, my point is, don’t throw away all planning and just wing it. You end up with Cowboy Coding and anyone who cares about the project being delivered won’t have any visibility into what’s going on. Get real by planning for the worst case.