Walking Through a Minefield AntiPattern

Velocity is an important part of modern software development.  However, there is also that adage that "speed kills."  Therefore, we need to strike a balance to avoid the "walking through a minefield' antipattern.  We have to avoid throwing away quality in our pursuit of quick turn around times.

Defining the Walking Through a Minefield AntiPattern

In this case, the name of the anti-pattern may be the best description.  However, we can add a little color to it. [Click Here to See The Page]

"Walking Through a Mine Field, as the name adequately suggests, is a situation encountered, most often, with software components and products which are not adequately tested and thus have residual bugs. These bugs turn up at critical times, for instance server overload etc. The name is given to this antipattern, possibly because one is never very sure of the effect of the untested/poorly tested component/product and thus lives in a constant fear of system failure."

The bottom line of this antipattern is the lack of quality.  We often attribute this lack of quality to a focus on speed and taking shortcuts.  However, there are cases where quality is just not a consideration in the creation of software.  In any case, we can avoid falling into this trap by giving quality assurance and testing the respect they deserve.

Just a Little Change

The easiest way to avoid the "walking through a minefield" antipattern is to ensure that our software is tested before release.  Unfortunately, this is easier said than done.  There are "quick" fixes and minor changes we see that can turn around a broken feature.  These lead us to the temptation of pushing through the "little change" without following the processes in place.  The dirty little secret is that there are no little changes.  Even the slightest change can introduce a new bug or have a typo that crushes the system.  Thus, we need to make sure we have proper checks and balances in place to reduce the chance of such bugs going to production.

Lack of Understanding

While the most common reason for this antipattern is a lack of quality, there are also cases where communication is the culprit.  In these cases, the problem solved by the software team is not the one users are focused on.  It may be due to subtle differences in understanding of the problem.  However, those little details can be frustrating to the customer when they are not being understood.  We need to remember that software tends to be complex.  We can follow the "measure twice, cut once" approach by slowing down, asking questions, and then following best practices.