Anti-patterns of design: Dead End

This article describes possible problems that may arise when modifying reusable components. It also provides advice on how to avoid these problems. The translation is the second in the series (one anti-pattern - one article), the link to the first translation is at the end of the article.

Title : Dead End
Other Name : Kevorkian Component (dead component)

The essence of the problem

Anti-stalemate is a result of modifying reusable components if the component is no longer supported and is not accompanied by its supplier. After making changes to the component, the burden of its support is shifted to the developers of the application system. Improvements in a reusable component cannot be easily integrated, and changes made can cause problems with its support.

In the case of commercial components, the antipattern is also known as Commercial Off-the-Shelf (COTS) Customization. When new releases become available, you will need to re-make special changes to use them, if they are possible at all. Sometimes for a number of reasons it becomes simply impossible to update a modified component, for example, because of the cost of performing repeated modifications or because of staff turnover (when the employee who performed the modification left the company).
')
The decision of an integrator to make changes to a reusable component is often considered as a workaround to eliminate the shortcomings of the supplier’s products. In the short term, this has a beneficial effect on the development of a software product.

Long-term support of such changes becomes irrational when they begin to struggle with the contradictions between releases of new software versions and reusable components. The only way to make changes to the component so that these changes are fully justified is to negotiate with its developer that your changes be included in the next version. But this is possible only if the goals of your changes coincide with the developer’s view of how his component should develop.

Solution to the problem

Customization of commercial components and modification of reusable components should be avoided. Minimize the risk of getting into a “dead end” by using modern platforms and infrastructure, as well as by making appropriate updates to the software being created as new versions of the components used are released (consistently).

When making changes is unavoidable, it is necessary to use an insulating layer (see the Vendor Lock-In antipattern from the Anti-Patterns of Software Architecture). Use an insulating layer and other techniques to remove the dependence of the software being developed on changes in the components used and on proprietary interfaces.

Exceptions

Anti-stalemate can be acceptable in test projects that are auxiliary for the main development, for example, in mock-ups, when advantages (flexibility or speed of modification) are achieved by making changes to the components used.

Note from the translator: you can go into a “dead end” not only when using components, but also when creating plugins that extend the functionality of the used third-party system. For example, when a plugin is written for a system of continuous integration and development workflow is closely tied to the functionality of this plugin. If the update of the integration system changes its API, then you will have to make changes to the plugin.

Other antipatterns

Antipattern design

• Poltergeist
• Dead end