Develpreneur: Become a Better Developer and Entrepreneur

The idea of technical debt is a hot topic among software development groups.  In particular, this concept shows up in agile efforts.  While it is more a concept than a pattern, we can use this as a pattern for our design and development work.  In fact, it lines up well with the Pareto principle and pushing details off until after delivery. The Technical Debt Pattern Defined I like to think of technical debt architecture as boxes and connections that are dotted lines.  We sometimes see a whole section of functionality surrounded by a dotted line fence.  These are referred to as future features or possibly optional.  These items are, in fact, technical debt in the design.  We are assuming they will be in that category before we even start on the solution.  The pattern can be handled through phases of implementation or the amorphous "future version" label. Applying The Pattern This pattern is easy to apply.  The designer or architect selects an item or items and designates them some form of future scope.  In Agile terminology, this is an assignment to the backlog.  The item(s) might even have some sort of special priority or designation to put them in a backlog that is pre-backlog in the process.  The term hold or ice is not uncommon for these items and implies how little with think of the priority.  While this approach can be a way to kick the can down the road, it is also a pattern for focusing on high-value features first.  These have less value by definition and we will get to them once the more important features are complete. Challenges Anytime we put an item on a backlog there is the danger it will never get brought back to be done.  Therefore, technical debt is almost an anti-pattern as well.  It can be a mechanism for sweeping features under the proverbial rug.  There must be ownership of these items and a push to ensure they do eventually bubble back up to be addressed.  That can require a strong product owner or project manager.  Nevertheless, it is possible and can provide working software for customers in a much shorter timeline.

The Cancer pattern has a word we do not have a favorable view of.  However, this pattern is becoming needed in more and more environments.  This pattern is one for conversions and migrations.  We do not always have a clean slate for our architecture.  Thus, we need designs to handle the modification of an existing architecture. The Cancer Pattern Defined The way Cancer evolves is that it replaces cells with something new while leaving things functional.  This approach is how we often want to replace a system in place.  We cannot shut things down and might not be able to do a swap.  The cancer pattern is a sort of "hot swap" of a system with a new solution.  We do not address the entire thing at once.  Instead, we selectively update, upgrade, or replace pieces at a time.  As time goes on, we can entirely replace the system.  Sometimes without end-users being any the wiser. Applying The Pattern The key to this pattern is to isolate the pieces of the original architecture.  We want to avoid making more changes than needed.  Likewise, we do not want to de-stabilize the current system.  Think of a Jenga game where instead of removing blocks from the stack, you are replacing them.  When we replace a piece of the system, we want to make sure we do it in a way that mirrors existing integrations wherever possible.  You can review the microkernel pattern for another way that components are viewed as a plug-and-play approach to functionality. Challenges Stability is the issue with this pattern.  When too much change is tackled in a batch, it can bring down the whole system.  There will also be integration details that can keep a component from being cleanly replaced.  Those situations can require some thinking layers or kludges to hold things together until we can craft a better replacement.  This pattern is also a time-consuming and complex one to implement.  You are not working from scratch.  Therefore, the original system needs to be understood in detail.  Then those details are used to map to the new solution.

We return to pick up a couple of new patterns.  In this episode, we look at the keep it simple pattern and how to apply it to architecture.  It is a pattern that we often overlook.  However, it is an essential piece of many successful solutions.  It is the heart of our desire to break complex things down into small pieces we can tackle. The Keep It Simple Pattern Defined We run into this pattern, or mentions of it, in many areas of life.  Software architecture is no exception.  When we face a decision to build a complex solution or a simpler one, we want to choose simplicity.  Yes, complex solutions can be fun to tackle and impressive.  However, they have more room for mistakes and a lower chance of success. That combination of low percentage success and high percentage for mistakes combines into a challenging anti-pattern.  Therefore, we use the keep it simple pattern to avoid that trap.  This approach is defined by a desire to keep every decision as direct and straightforward as possible.  While the solution may not be simple, it is an attempt at the lowest common denominator approach to solving a problem. Applying The Pattern We have seen numerous ways to implement this pattern in our look at patterns and anti-patterns.  First, we break down our solution into smaller problems.  Then, we build solutions a bit at a time and put them together for the overall solution.  The pattern is to avoid adding complexity unless we are forced into it.  Clever solutions can impress others.  However, they also are not helpful as a foundational piece for a larger solution.  We want to build solid, stable, and reliable bricks to craft our solution's strong foundation. Challenges There is a sort of boredom or lack of excitement from simple solutions.  They do not challenge us as much as big hairy audacious obstacles.  We must remember that the goal in building a solution is not to make it fun or challenging for the implementors.  The goal is to provide a solution that satisfies the customer.  When we focus on the problem and a direct solution, we are more likely to apply this pattern.

We looked at an incorrect focus based on faulty data analysis in our prior episode.  This time we explore solving the wrong problem with the misdirection anti-pattern.  While this situation can arise from the data bigotry anti-pattern, it is often a failure to grasp requirements fully.  It is a problem that comes from improper focus and lack of communication.  Those are two prevalent weaknesses in a project that lead to challenges and even failure. The Misdirection Anti-Pattern Defined This anti-pattern is simply defined.  We are not solving the correct problem.  Yes, there is a  problem described, and it might even be correctly addressed.  However, it is a red herring of sorts and not what we need to solve to make the customer happy.  Similarly, it may solve the problem but in a completely irrelevant way.  That second situation can make this tough to assess.  Likewise, it can render an entire architecture obsolete or insufficient. The Anti-Pattern In Action The misdirection anti-pattern often arises when the focus is on the answer rather than solving a problem.  Thus, we can even pass through QA and testing with flying colors.  We get the correct answer while reaching it incorrectly.  When we "show our work" for the solution, we get a zero for that portion.  Similarly, the incorrect solution will often fail to address outliers adequately and may fail to solve it for all happy paths. My favorite example is a request from years ago.  We spent weeks working on building a report that could display hundreds of thousands of rows in a reasonable amount of time.  The query result set was huge, and even paging was slow.  They needed the whole report but only cared about the last page.  That is where the misdirection anti-pattern became apparent.  The actual goal was to get a count of records.  The details of each record were not helpful in this situation.  Thus, the query only needed a summary and not all of that detail.  Unfortunately, this is not at all uncommon.  There are many examples of reports and results with a lot of detail that is often ignored.  The wrong problem was solved.  Therefore, the summary data provides the answer, while the details are extra work that is not needed.   Avoiding The Anti-Pattern There is a useful method architects use to gather requirements.  They follow each answer to a requirement by, "and then what?"  That approach helps us avoid this anti-pattern.  It requires a solid understanding of the problem and also its context.  We can not ask about pain points and then jump right to relieve those.  Instead, have a conversation around the issues and obstacles that highlights the various options available.  This process includes suggesting a couple of solution approaches to determine whether the pain point is the source of the problem.  It is like a doctor that asks a patient what hurts, and instead of addressing the hurt, they dig to find its source.

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.