Develpreneur: Become a Better Developer and Entrepreneur

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 the proper stream or flow of data. Think of a series of plumbing pipes.  Different liquids or temperatures flow depending on the pipe.  Our horizontal and vertical pieces of the solution are similar.  There might be very different items in each.  Likewise, the connections from one to the other can quickly become confusing and turn into a jumble. The Anti-Pattern In Action Almost every solution has general components and those specific to the problem.  While we can keep all components as stand-alone to the particular solution, it is better to utilize general components as well.  We see this creep in when components have to pass around a lot of data.  A need to change the source code of a framework or library also points to a jumble.  The mixing of vertical and horizontal components often leads to "breaking" well-encapsulated code.   Avoiding The Anti-Pattern The first step in avoiding this anti-pattern is designing your solution with an eye to problem-specific components and general pieces.  Next, do not intermingle those components.  They have different inputs, outputs, and purposes.  Thus, we need to keep our design focused on the task at hand and not allow the architecture to sprawl into areas that are not needed.

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 the readers. The Anti-Pattern In Action The funny thing about this anti-pattern is that it results in documentation that often sits on a shelf.  The readers quickly see how pointless the documents are and stop reading.  That creates a lot of busy work without productive outcomes.  It is an anti-pattern of spinning your wheels.  A lot of activity is occurring.  Yet, no progress results from it.   Avoiding The Anti-Pattern The best way to avoid this particular anti-pattern is to keep your focus.  There is a "why" for a project and for the architecture.  That includes the related documentation.  When the work is not contributing to either understanding or productivity then adjust.  That adjustment may be a change in process or halting something completely in a paradigm shift.  Of course, the best way to avoid the problems in getting away from this situation is to never get into it.  Keep things simple and direct.  That goes a long way towards following a proper and useful pattern.

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 magic numbers.  Those last errors come from attempting to do too much in one place. The Anti-Pattern In Action Confusion is the word of the day with this anti-pattern.  The users do not see a simple input and output or series of those in the architecture.  Instead, there are large or monolithic components that have dizzying descriptions.  Think of a database with a single table and several conditional fields or values.  There is too much to absorb and keep track of.  Again, the exact opposite of breaking down a problem into digestible chunks.   Avoiding The Anti-Pattern Like many anti-patterns, we avoid this with intention and simplicity.  There is a balance in a good solution between doing work and staying focused.  We avoid tripping over this mistake by sticking to our focus on the problem and solution.  While it is valuable to ask "what if?" questions, that can lead to an attempt to handle too many variations.  Stick to reasonable and likely paths, and your solution will be much easier to understand and manage.

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, there needs to be a controlling decision-maker that drives things forward and understands the primary goals. There are names for this anti-pattern, like gold-plating and adding bells and whistles.  These additions and enhancements are not the problems in themselves.  Nevertheless, they often create a slippery slope of tweaks and minor changes that lead you right over a cliff.  Once we decide to make an allowance for one person or side, then we face the argument that it is fair for other voices to get their desires.  Look at governmental politics for examples of exactly how bad things can become. The Anti-Pattern In Action Lack of direction is the best description of this anti-pattern.  The core why of our problem and solution are lost in discussions and requests.  Not only is this an obstacle to success, but it also leads to other anti-patterns.  That includes the one we all fear, the death march.  The project languishes in changes and moving the finish line.  That is demoralizing and costly even while it waters down the solution.   Avoiding The Anti-Pattern Owners and decision-makers are the cure for this anti-pattern.  That changes the focus from "make everyone happy" to making that person or people happy.  It also cuts down on time spent making decisions and discussing options.  We are not running away from feedback.  Instead, we are keeping feedback focused on the problem and solution that launched this project.

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 experience and understanding of a pattern or approach are not always the same as our teammates.  Thus, we may think everyone is on the "same page" when multiple views are involved.  That can be either the situation or the approach we are taking. The Anti-Pattern In Action Lack of documentation and minimal design often lead to this anti-pattern.  It also occurs more frequently in larger teams than in smaller ones.  A group of two or three people is more likely to be synchronized on the solution approach.  Likewise, communication is more manageable and better with fewer people involved.  Once the team grows to multiple teams or groups, documentation becomes critical.  It is the first step in ensuring everyone has the same understanding of the approach. A vital factor of this anti-pattern is point-of-view.  When different groups look at a solution, they may have different views of its construction.  That leads to gaps, blind spots, and incorrect assumptions.  For example, look at the classic Volkswagon Beetle.  It is easy to assume the engine is in the front of the car.  However, it is in the rear.  Think of how many problems can be caused by such an incorrect assumption. Avoiding The Anti-Pattern This anti-pattern boils down to communication.  We avoid it by spending time designing and documenting our architectural approach.  Next, share those documents with all of the team members.  The result is every member can see what the plan is.  Finally, they are confident that the rest of the team has the same understanding. This solution is simple.  However, we will see that many anti-patterns are easily avoided similarly.

We wrap up our patterns focus with the space-based pattern.  This is also known as cloud architecture.  We will see how this approach allows us to break out the solution into components suited for scaling.  We solve the problem of scalability in architecture instead of tools. The Space-Based Pattern Defined We have often seen layers in our architecture discussions.  Similarly, this pattern breaks out each layer into many workers.  Therefore, it is described as a collection of grids.  First, we have processing units that do the bulk of the work.  We then have a virtual middleware composed of messaging, data, processing grids, and a deployment manager. Applying The Pattern We see in the above list of components that each step of functionality in an application is broken out.  However, the critical piece is the processing unit.  There is often a bottleneck somewhere among the layers.  We avoid that by replicating the entire solution across processing units in this approach.  Then we can laterally scale out the solution by adding more units. This solution may seem obvious and straightforward.  However, keeping those processing units in sync requires overhead.  We are replicating data and code.  Thus, breaking the reliance on a single database or store.  That often is the limiting factor that we are now getting away from. Challenges Synchronizing the components is the hardest part of the space-based pattern.  Each piece needs to fulfill the requirements for the solution and "know" the current state.  Of course, a stateless solution makes this a breeze.  However, that would essentially be a microservices architecture.  This approach needs more information to provide the necessary services.  Nevertheless, this also is a solution that tends to be perfect for high availability.  When you have units shut down, you launch more to recover from those downed components.

We come to one of the best patterns for breaking a big problem down into bite-sized pieces.  The microservices architecture pattern is a perfect fit.  The objective is to farm out work to one or more services that are small and well-defined.  This pattern is one that has grown in popularity and is often seen in Cloud solutions. The Microservices Architecture Pattern Defined The architecture is another one that has three primary components.  There are client requests, an interface layer, and service components.  Likewise, the microservices architecture is another distributed pattern that allows the solution to grow as needed. In general, requests are directed to services via the interface layer.  That layer also can bundle or roll up responses so any request becomes a series of microservice requests.  For example, we can split up reading from a file into a service that gets data, another that parses the data, another that does validation or computations.  Finally, one that formats the results for output.  We keep the services as small units of work that are well-defined and have a large number of uses. Applying The Pattern As noted, this is another distributed pattern.  We take the problem and split it into small units of work.  In this case, the small is micro and gives us the name.  We gain the benefit of having a worker that is able to solve a general problem.  Thus, we can re-use the workers and not only the source code.  That can be a huge productivity increase.  Likewise, we can create tight and high-quality workers that provide a foundation that rarely changes or needs updates. Challenges We can overdo this pattern.  It is like many where we want to use bricks for our solution, not sand.  There are problems that do not need to be reduced to smaller parts.  Once we hit that level, create the service and declare victory.  However, we need to be cognizant of the resources required for our services and ensure they do not rise above the level of "micro."  We want a solution of small steps, but not too small.

The focus of this episode on software architecture patterns is the microkernel pattern.  It is a common way to build on core technology without the need for future design.  Once the plugin interface is defined, the sky is the limit for enhancements and upgrades.  You do all of this without impacting that core. The Microkernel Pattern Defined This approach starts with a core piece of functionality.  Next, other components are added to it.  We see this pattern utilized in many cloud products and commercial software.  The core can be protected, and then plugins farmed out.  Also, customers can purchase the core and then plugins a la carte.  In a technical sense, the core provides shared functionality across the system.  The plugins allow us to upgrade or enhance the core in a focused way.  The core is not touched with this pattern and can provide a stable foundation.  The enhancements are plugged in and thus not likely to impact the overall system negatively.  We define the interface that allows for the plugin, and then it is up to future developers to expand on the solution.  The plugin interface is often thin and straightforward, leaving the plugins nearly stand-alone modules.  Likewise, we can split a more extensive solution into smaller pieces that are easier to manage. Applying The Pattern The opportunities are endless for this pattern.  We can solve small problems with hooks included for plugins.  Likewise, we can build enterprise systems that allow for future expansion.  Of course, there is an overhead cost of a plugin interface.  However, that can often be kept to a minimum when limited data needs to be shared.  Finally, there are many examples of this pattern out in the wild, and a search can find excellent reference projects. Challenges The best use of this pattern is when you have a well-defined core and multiple implementations of some features.  Note that the plugins can be numerous and different in the service they provide. For example, the various ports on the back of a desktop computer provide different plugin options.  We can leave some of our implementation details for the future and focus on what we have in front of us today.  The microkernel architecture allows for "plug-and-play" options and testing partial solutions.  That adds up to excellent benefits.

We continue our season of software architecture patterns and more by reviewing the interpreter pattern.  This one may seem familiar.  It has been discussed in other areas of software development.  However, it is worth refreshing our memory on this helpful solution. The Interpreter Pattern Defined The way this works is to start from a client, and given a context; we receive an expression.  That may be a very simple or complex series of "sentences."  Next, the expression is broken down into parts that are individually interpreted.  Finally, the combined results are sent back.  That gives us yet another pattern that involves breaking the big problem down into smaller pieces.  Thus, it is easier to solve. Applying The Pattern There are many opportunities for us to create a language in software and then use an interpreter.  Likewise, every computer science student has spent some time with these sorts of problems.  Of course, every computer language has this pattern implemented in some way.  While the interpreter pattern may seem difficult to apply, it has potential in many areas.  Therefore, it is worth considering as you design your approach.  As you will see, it is another way to chop up a big problem into more manageable bites. Challenges This pattern is based on splitting up the work (interpretation) into stand-alone steps that can be mixed and matched as needed.  The challenge is to avoid interdependencies wherever possible.  The less each unit of work links to others, the easier it is to build and re-use the solution.  There is also the problem of walking through a sentence or complex expression and breaking it into component parts. For example, think of diagraming a sentence.  It is not always a natural way to think about a request.  However, you can build from simple expressions up to complex ones.  Next, use testing to confirm you are on the right track.  Thus, the solution often ends up much easier to maintain than a holistic approach.  The focus is on components instead of the permutations of expressions.

The blackboard pattern is arguably the least known among our first group.  This is a pattern that is not common because it is best used with some specialized tasks.  However, you may be familiar with it if you work in speech recognition, vehicle tracking, sonar signals interpretation, or similar open-ended forms of searching and matching. The Blackboard Pattern Defined Three appears to be the magic number for parts of an architectural pattern.  Likewise, this pattern again has three concepts that make it up.  There is the blackboard, the knowledge source, and the control.  These parts work together to match data to a solution. The Blackboard pattern uses the idea of a blackboard as a place to hold global data.  We can inspect or update the blackboard.  A knowledge source can update the blackboard, and we can have multiples of these.  Then, the control works with multiple sources and interacts with the sources and the blackboard.  The control effectively loops through sources looking for a solution and then posts that solution once found.  Thus, this approach allows us to quickly match known solutions or expand available solutions when a new one is needed. Challenges We can simplify the blackboard pattern to a form of complex pattern matching.  We are looking through data and determining whether it is new or matches a known solution.  Therefore, the whole pattern is rather loose in its definition.  We can use this to group things like socks of the same color shades or audio of various musical instruments.  Thus, we are doing complex work, typically in the control component.  Likewise, we have an open-ended solution set that can sometimes take substantial time to build out.  The pattern is simple in design.  However, the implementation can be very complex.