One of the funny things about anti-patterns is that they are obvious in the name alone.  We might not know what it is but everyone avoids a jumble.  There is no technical knowledge required to judge this is not a good idea for a solution architecture.  In this episode, we review the jumble anti-pattern, what it looks like, and how to avoid it. The Jumble Defined The key to the jumble anti-pattern is horizontal and vertical elements of the design.  We want to keep those separate much like in Ghostbusters, do not cross the streams.  There should be a clear usage for a component either in the horizontal or vertical sense.  That allows us to use them properly and within... Read more

Overkill is a theme among many anti-patterns.  The cover your assets approach is one of those types where it just goes too far.  There is nothing wrong with providing a solid paper trail and communication.  However, we can make documentation the point and miss the true goal of a project. Cover Your Assets Defined This anti-pattern is the same as documentation for documentation’s sake.  We get lost in administrative red tape, but do not make it to analysis paralysis.  The whole project becomes thinking about the architecture and documenting it.  However, decisions do not get made.  Instead, there is a lot of discussion and options provided.  That all adds up to loose ends and is a waste of time for... Read more

Much like the make people happy obstacle, we have the Swiss Army Knife Anti-Pattern.  This mistake is another example of over-architecting a solution.  Think of it as throwing everything into a design instead of thinking through what is needed.  However, this approach is not gold-plating and bells and whistles.  Instead, it adds things “just in case” they are required. The Swiss Army Knife Anti-Pattern Defined We often have pointed out patterns that break down and simplify a problem.  The Swiss Army Knife Anti-Pattern is almost the opposite of that.  Instead of breaking a problem into smaller parts, there are fewer, more complex components.  That leads to complicated usage and often confusing results.  Even worse, this anti-pattern creates side effects and... Read more

One of the most amusing anti-patterns is the one known as “make everyone happy.”  The funny thing is that it never does.  Instead, it points us to an old bit of wisdom that you end up pleasing no one when you try to please everyone.  Put more simply; you cannot have more than one master.  If this seems familiar, we have discussed it under the name “design by committee” in prior posts. Make Everyone Happy Defined You have heard that two heads are better than one.  Unfortunately, that does not translate to more is always better than less.  In particular, design and related decisions suffer greatly from too many voices.  There is nothing wrong with seeking feedback and input.  However,... Read more

The series switches gears to look at anti-patterns.  We start with the mother of all anti-patterns, architecture by implication.  Any time we have a pattern that includes assumptions, success is a challenge.  Looking ahead, the next several episodes will explore familiar anti-pattern names.  We will find that many coding anti-patterns can also be applied to architecture.  Likewise, these are ways to approach enterprise solutions. Architecture By Implication Defined This anti-pattern is wrong in the implication part of it.  Any architecture that involves implications and undocumented features is an anti-pattern.  The core challenge is that pieces of our architecture are commonly known.  That familiarity breeds a sense of “we all know this.”  However, it is a dangerous assumption to make. Our... Read more