Anyone who has been following this blog (or knows me in other venues) should be aware that I am a big fan of Patterns. The application of Patterns was first popularized with respect to software development just over 20 years ago with the publication of the book Design Patterns: Elements of Reusable Object-Oriented Software by the infamous Gang of Four (Rich Gamma, Richard Helm, Ralph Johnson, John Vlissides), but there role of patterns extends far beyond Design Patterns.
So, who should a Pattern be? The most common answer given is “recurring solutions to common problems”, but this leave off a critical component. Every well defined Pattern has a set of conditions which indicate that the Pattern may be appropriate, as well as a set of conditions that counter-indicate application of the pattern.
Conversely, an Anti-Pattern is something that may appear to be a solution of a problem, but the recurring effect is that the solution is itself problematic. Once again there needs to be a defined set of conditions that dictate the consideration of an approach to be an anti-pattern – and this is one of the things most often missing. Think back to how many times you have heard or seen “ZZZ is an anti-pattern!” without “ZZZ is an anti-pattern when YYY” or at least “ZZZ is an anti-pattern unless WWW”.
As soon as one becomes diligent in evaluating the indicating and contra-indicating conditions, something very interesting is likely to be realized – Conditions change over Time! Yet, once something is considered to be a “good” Pattern or an Anti-Pattern that label tends to persist far beyond the timeframe where it was applicable. Yet it is nearly universal that people will continue to utilize certain approaches (because they have been accepted as Patterns) and avoid other approaches (because they have been declared to be anti-patterns). The resulting cargo-cult mentality directly leads to the phenomenon of “A minor or secondary part of something controlling the whole” better known as the tail wagging the dog.
When this occurs at the software design and implementation level, the effects are bad enough. A few years ago I was retained to confirm that .NET was not a viable implementation platform for something the client had previously done in Java. They had build a .NET version, but the performance was horrid. Since they had carefully followed all of the patterns that had allowed them to produce excellent performance in Java, surely the problem was with .NET and not with their usage (at least that is what they were convinced of). In a very short period, I was able to demonstrate that differences (primarily in memory management and garbage collection) between the two runtimes was the root of their problem, and that many of their Successful Patterns (for Java) were actually Anti-Patterns (for .NET). Even a naive (simple) implementation in .NET was nearly an order of magnitude faster than their “highly optimized, pattern driven” implementation had been! [note: the reverse is also true, many excellent Pattern implementations for .NET will perform horribly when transcribed into other languages/runtimes].
As bad as that was, it pales compared to what happens when keeps a static view of the value of specific Patterns (or harm of specific Anti-Patterns). At the ALM level, this can easily be triggered by the evolution of the toolset (or a change in toolset) and/or the evolution of the team/environment. Entire approaches to work management, source control, quality monitoring and reliable delivery can be skewed because decisions are made on something having been declared either a Pattern or Anti-Pattern at some point in the past, rather than seriously considering the current conditions, desired future state and other factors in light of new information.
In conclusion, I want to remind everyone that I am a big fan of Pattern based approaches, they are great ways to utilize what has been learned in the past, both about what one may want to do, and what risks may be associated. But I strongly encourage everyone to make their decisions based on actual conditions and not blindly allow the secondary nature of Patterns (the tail) to have an undue influence on the real goal – the effective achievement of your team’s specific goals in a manner that takes into account your unique conditions; because that really is the Big Dog!