Autogenerated Stovepipe - An Anti-Pattern

In an effort to re-use our previous work, we can over-simplify a solution.  One such situation is when we grow from a stand-alone system to a distributed one.  This particular anti-pattern is a facet of the autogenerated stovepipe.  Even the best solution in one case is not always going to be a good one to move to an enterprise or a distributed approach. Defining the Autogenerated Stovepipe Anti-Pattern There are several definitions of this anti-pattern.  In this episode, we use the source-making definition to drive our discussion. [Click Here to See The Page] "This AntiPattern occurs when migrating an existing software system to a distributed infrastructure. An Autogenerated Stovepipe arises when converting the existing software interfaces to distributed interfaces. If the same design is used for distributed computing, a number of problems emerge." I find this to be an almost obvious anti-pattern.  However, we do not always see the obvious implications of moving a solution to a different approach.  The good news is that we can often see what others have found in their similar attempts.  Thus, we can avoid an autogenerated stovepipe through abstraction and thorough design. New Environment,  New Problems One of the problems with trying to re-use code and designs is making sure they fit in a different paradigm.  A simple environment allows us to solve problems without getting overly complicated.  However, those more straightforward solutions may not scale to more complex environments.  Nevertheless, we do want to re-use code as often as possible.  With these conflicting goals in mind, we once again need to look to abstracting our functions and methods where possible.  This best practice is a perfect solution for our struggle.  Write code that is a good fit for the complexity you need to address.  This situation is precisely why we want to create code that can be extended or shifted to another implementation in the hierarchy. A Game Plan While many of the issues that may arise in a move from one environment to another are apparent, they can easily be missed.  Thus, it always helps to start these sort of "migrations" with some time considering the essential differences.  While this does not guarantee the process will be flawless, it does reduce the risk of surprises.  Those fundamental differences are valuable in mapping out the extensions and enhancements your new solution will need.  These will allow you to take advantage of the existing one.