Death By Planning - A Rigid Anti-Pattern

Death by planning is an anti-pattern that makes us look like lemmings.  We make a plan, and then we follow it mindlessly.  This approach can work for some projects like building a house.  However, software development does not work this way.  There are always changes and unknowns that we encounter during the SDLC process.  Thus, we want to be able to adjust to those instead of staying rigidly to the initial course.

Defining the Death By Planning Anti-Pattern

The Sourcemaking site provides the definition we will use for this episode.  It is lengthy, but this anti-pattern calls for that. [Click Here to See The Page]

"In many organizational cultures, detailed planning is an assumed activity for any project. This assumption is appropriate for manufacturing activities and many other types of projects, but not necessarily for many software projects, which contain many unknowns and chaotic activities by their very nature. Death by Planning occurs when detailed plans for software projects are taken too seriously."

The primary factor in this anti-pattern is that last sentence.  We gain value from creating detailed plans.  However, they should be taken with a grain of salt.  We often run into situations that are much like a battle where all the plans are thrown out after the first shot is fired.  It is rarely that dire, but software development should no more be a slave to design than an army is to a battle plan.

It Is Not Entirely Academic

One of the common arguments from those that follow this anti-pattern is the design is the "right" way to proceed.  The idea is that the time put into planning needs to be respected and veering from that course will invalidate the plan.  This mindset often comes from an academic environment where the process is considered the critical thing to focus on.  Once we get into the implementation phase of the SDLC, the solution is the key thing.  The process is there to help us, not shackle us.

If a Process Occurs And No One Notices...

While it may be tempting to skip the design and related processes, that is not the solution to this anti-pattern.  Death by planning is not a problem because of the planning part.  It is a bad practice when you focus too much on the plan.  This is not very different from most things in life.  Things are best when done in moderation.  Too much of anything throws off the balance.  In this case, it is worse because of planning being a secondary part of the life cycle.  The goal should always be building a solution.  Every other best practice is there to help us achieve that primary goal.  Therefore, rules (and even design decisions) are made to be broken.