Death by Planning is a management anti-pattern that occurs when a project is planned so thoroughly that the development team runs out of time to actually build it.
The problem is that the teams involved in this anti-pattern believe they need to know everything before than can start building. This is, of course, impossible. So what do should we do instead?
We should just build the damn thing.
The Rundown
- Name: Death by Planning
- AKA: Detailitis
- Summary: Occurs when a team attempts to plan out a project so thoroughly that they run out of time to actually build the project.
- Type: Management
- Common?: Jenkins! Call a meeting so we can decide on this!
Tell Me a Story!
By my very nature, I am an architecture astronaut. I want to build the perfect program, the one that does what it needs to, is testable, is easy to change, is modular, is cheap, is robust, is all the other positive adjectives you can think of. My brain, left unchecked, will spend all its energy trying to come up with the perfect architecture.
This is, of course, ridiculous. It's ridiculous partly because no one true architecture exists, but mostly because I can't actually let my mind spend this time; if I did, I wouldn't get any actual work done.
Of course, I only know that because I've done it before.
Remember the Cafe project? The one that I talked about in the Reinventing the Square Wheel post? That project had a myriad of issues, and one of them was that my team, myself included, felt the need to plan it out to the fullest extent.
This included having entire meetings devoted to the text displayed to the users on the page, with questions like "Should we show the short name of the item or the full name?" and "What happens in a power outage?" and "What color do the display devices need to be?"
I wish I was kidding.
Now, if those sound like thoughtful questions, perhaps you're an architecture astronaut as well. This is not a bad thing by itself. Where it gets to be bad is when you get lost in the details, as we were.
The supposed "Cafe point-of-sale" took nine months. The first six were filled with planning meetings. We didn't come close to completing it. The project died, in part, because we tried to plan so many things out that we couldn't actually finish building it. It remains the largest single project I've ever worked on that didn't make it to production.
Strategies to Solve
Could we have saved the Cafe point-of-sale project from its death-by-planning fate? Sure, but that needs to happen very early. Modern software development has recognized the problem that death by planning poses, and adapted. That adaptation is now commonly called iterative development, or more succinctly, Agile.
No matter to what extent you agree with the implementation behind Agile development, the goal is the same: build things in short, controlled segments, delivering a working product as soon as possible, and then making changes to that product as becomes necessary. The majority of the software world has moved to some variation of this idea, because software as a product is volatile and must adapt quickly.
At the time, my company was in the infancy stages of adapting Agile methods. This project, and its failure, spurred the company on to adapting Agile more quickly.
Iterative development, making a minimum-viable product (MVP) and then changing that product in small, measured ways, is how you avoid death by planning.
Summary
Death by Planning happens when a project fails because the team took too long to plan it out, usually due to a zealotry for details. We can solve it by taking large projects and breaking them down into manageable pieces, and building those pieces in steps. One step at a time, we can make a project that does what it needs to do.
Did one of your projects fail because of death by planning? Can you share anything about it? I'd love to hear it! Share in the comments! Or else head on back to the series index page to see some more anti-patterns.
Happy Coding!
