Develpreneur: Become a Better Developer and Entrepreneur

This podcast season is a great excuse to highlight new anti-patterns.  We look at a new one we call statistical bigotry in this episode.  That is an excellent emotional word and a common challenge across many areas of problem-solving and debate.  This anti-pattern appears when we give too much weight to our data and improperly use statistics. Statistical Bigotry Defined We use data and facts to support our decisions regularly.  However, we can not blindly use data in this way.  We need to ensure the basis for our decision is based on overall reality instead of a small subset.  When we improperly use a small subset to assume the whole, we are committing statistical bigotry.  The issue may arise from anecdotal data or other situations where the information is given more weight than it deserves. For example, we see this in cultural discussions all the time.  An example is when someone says everyone or no one they know does or believes X.  That may be entirely true.  However, it is also utterly irrelevant to the discussion. The Anti-Pattern In Action Statistical bigotry is a focus problem when crafting solutions.  We spend too much time or resources on something that appears essential but is not.  Thus, the solution is imbalanced in its approach.  Unfortunately, It is not always immediately apparent.  For example, we may think a particular feature needs to be highly tuned due to its use.  Then, when it goes out to real users, we find that highly tuned functionality is rarely used, and another one was ignored that is needed. This situation also can arise when we start to see actual data in a system.  Row counts and result sets are different in reality than we saw during development, and performance bottlenecks arise.  The issue is not that we did not tune our solution.  We just misplaced the emphasis.   Avoiding The Anti-Pattern This anti-pattern is one of focus.  We will see others in this area, and intelligent testing is often the way to avoid these anti-patterns.  While the testing will not reach the "real world" data levels, it will help us see where our focus has been in more of an apples-to-apples comparison.  The issue of spending too much time on one area at the expense of another is far more likely to appear as a result.  Ideally, testing also brings in more real-world usage than during development.  Likewise, it provides a different and new view from the implementor's focus.

We have highlighted many areas of quality software development.  However, the stovepipe enterprise is a maintenance anti-pattern.  This situation occurs when we build a system that has a high maintenance cost.  Even worse, maintenance often requires to be done quickly and more as a patch than a build.  Therefore, we produce a house of cards that becomes more fragile as time goes by. Stovepipe Enterprise Defined Stovepipes are historically a form of a kludge.  Wood-burning stoves needed a way to get rid of the exhaust, and it goes through the pipe.  However, the material often wears down a stovepipe quickly, and it is patched with whatever materials are available rather than replaced.  We see this in software solutions when we have high maintenance areas of the architecture.  That frequent touching of the system can introduce bugs and reduce the overall quality.  Stable is better today, but it also makes it likely we will have working software tomorrow. The Anti-Pattern In Action There are a few typical results from this anti-pattern.  One is the constant requirement for coding (bugs or enhancements) to an area of the solution.  Another is a form of fire-fighting approach to parts of the system.  In the latter case, we regularly see issues in code sections and have to do a quick fix rather than refactor or redesign.  The solution itself is essentially flawed in this case, even though it does the job.   Avoiding The Anti-Pattern Shortcuts are a leading indicator of stovepipe enterprise.  We make design decisions or craft solutions that are suitable but not ideal.  Sometimes a less-than-ideal solution works out fine.  For example, in an 80-20 approach, the "eighty percent there" portion of it supports our needs.  On the other hand, that last twenty percent is needed to provide a complete solution.  The missing pieces change maintenance and stability in many solutions.  That is where the anti-pattern starts to show.

The "warm bodies" anti-pattern is sometimes subtle.  However, it can be frustrating and sink more than a project.  This approach is based on the fallacy that more developers or resources will create better software sooner.  Instead, the reality is closer to the idea of getting nine women to give birth to a baby in one month. Warm Bodies Defined This anti-pattern is an attempt to work faster or get a project back on track by adding resources.  It often is identified by a manager hiring more team members to address complex or time-consuming parts of a project.  Unfortunately, architecture is not immune to this.  The challenge comes when the architecture is complex, and there is a temptation to fix that by creating a more extensive implementation team to compensate.  That is where the anti-pattern rears its head. The Anti-Pattern In Action Fortunately, this anti-pattern is easy to spot once it kicks in.  The response to design and architecture challenges is to add to the team.  When team size is driven by architecture or design, you are on the slippery slope to an anti-pattern.  It harkens back to a common practice in the past of improving an application response time by purchasing more or larger servers.  Resources are not a good way to fix design flaws.  Likewise, laws of time and physics preclude the "warm bodies" approach to improvement.   Avoiding The Anti-Pattern Simplicity is always going to be the better approach than a complex solution.  We can avoid this anti-pattern by sticking to realistic expectations and designing accordingly.  Part of your estimation strategy and improvements should be an attempt to determine minimum time frames around projects.  For example, you will find a minimum time required to create even the most straightforward solution given unlimited resources.  General overhead and interactions make it impossible to do better.  Once you know some basic metrics like minimum deployment time, you can set baselines and assess estimates.  Glaring mistakes and over or under-estimating will make it easy to adjust and get on track before this anti-pattern appears.

This episode covers the vendor lock-in anti-pattern.  It is another one that we have seen before.  However, it is slightly different when you apply it to software architecture.  This situation is fascinating as we can fall into it thinking we are making the best decisions.  However, comfort and ease are not always the best way to assess our solution.   Vendor Lock-in Defined This anti-pattern occurs when we craft an architecture that hinges on a vendor or third-party product.  Sometimes the vendor is an open-source tool or approach.  While that is far better and can save us from being locked into their solution, it is still important to recognize.  We will be better off when we are free to craft our solution to our problem than we are chained in some way to a general offering.  In short, vendor lock-in occurs when we are bound to our solution, and someone else controls its growth and support. The Anti-Pattern In Action There are many ways this can appear in your solution.  However, the symptoms tend towards heavy reliance on third-party support or releases.  When you are often referring back to a vendor to plan your approach and schedules, you are likely in the vendor lock-in situation.  There are cases where this is acceptable.  However, vendor fluctuations and business objectives can dramatically impact your solution and even cause it to fail.  No solution or organization is too big to fail.  Therefore, proceed with caution when you rely heavily on a vendor or vendors.   Avoiding The Anti-Pattern Vendors exist to assist us.  They provide products and services that increase productivity and reduce costs.  Thus, we do not need to avoid them altogether.  We need to be strategic in our use of them.  It is best to include contingency plans as well.  Lock-in can be a minor issue if we have ways to quickly move off of or away from a vendor.  Of course, having complete control of our solution, such as offered by open-source technologies is always the safest way to avoid reliance on outside parties.

This next anti-pattern is "reinvent the wheel."  It is not a rare issue in solving problems.  However, it is still worth exploring.  Knowledge is not enough to avoid it.  Otherwise, it would be less common.  Likewise, the speed of progress in technical solutions makes it a challenge to keep current and avoid this anti-pattern.   Reinvent The Wheel Defined We see this in many ways.  However, it always boils down to looking at a problem as a novel challenge, rather than something already solved.  The anti-pattern can appear from ignorance through to a false sense of accomplishment by solving any problem.  These lead us to be busy solving problems we could move past rather than productive.  It is the height of busyness over productivity. The Anti-Pattern In Action The result of this approach can be hard to see.  It is the act of taking a wrong path that is not going to be obvious unless the correct path can also be seen.  Therefore, we can merrily plow forward in a "reinvent the wheel" trap without knowing it.  That is why we need to spend time doing our due diligence and research into a solution before we implement it.  Otherwise, we will never know what we do not know.   Avoiding The Anti-Pattern The many ways this anti-pattern appears can all be addressed through research.  There are far too many sources available on the Internet for reviewing similar problems and retrospectives.  These can point to, or describe in detail, solutions your team can utilize.  Thus, a little time upfront can save a lot of time spent on implementation.

Communication and consistency are key traits of patterns.  Likewise, a lack of these creates anti-patterns like the wolf ticket.  We all know that standards are helpful and a worthy pursuit.  However, there are de facto standards that can cause us headaches.  Let's look at how a good intention can turn into an anti-pattern. A Wolf Ticket Definition A wolf ticket is not that different from smoke and mirrors.  It is a standard or other conforming to rules where there is no enforcement.  Buzz words are a common example.  We see a word or phrase thrown around because it is the hot topic of the day.  However, there is a lack of vetting or validation to ensure compliance.  While people may tend to go the same way and have the same view of the architecture (in our case), there is no way to prove that is the case. Therefore, a wolf ticket is related to a wolf in sheep's clothing.  We think we are doing the right thing and it looks good from the outside.  However, an anti-pattern lurks beneath the surface. The Anti-Pattern In Action We have seen similar issues in other anti-patterns that are driven by assumptions.  This one is no exception.  We start with a good intention of looking to standards.  There are many benefits to standards and we will not rehash them here.  However, we fail to document and define those standards.  Instead, we just sort of let them happen organically.  While there is some value in this as a starting point, the lack of a formal standard can bite us. For example, the web is based on a standard for HTML and related technologies.  Browsers have to support these in order to work properly.  However, there are extensions that grew based on needs.  These sort of fell into standards but were not defined enough.  That led to issues with browsers being inconsistent in what they supported and how.  The base standard was consumed by a wolf ticket anti-pattern and countless headaches were created.   Avoiding The Anti-Pattern Clarity and validation are the two ways to avoid this particular anti-pattern.  We need to be clear on what is and what is not a part of any standard (or architecture) we create.  Likewise, there must be a way to validate adherence to the standard.  Unit and regression testing are excellent tools for building in and confirming adherence.  However, there are many other ways including documentation and code reviews.

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.