Antipatterns of Design: Dead End

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

Name : Dead End (dead end)
Other name : Kevorkian Component (dead component)

The essence of the problem

The antipattern “dead end” is the result of modifying reusable components if the component is no longer supported and not accompanied by its supplier. After making changes to the component, the burden of its maintenance 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, then to use them you will need to re-make special changes, if at all possible. 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).

An integrator’s decision to make changes to a reusable component is often considered a workaround to address supplier shortcomings. In the short term, this has a beneficial effect on the development of the software product.

Long-term support for such changes becomes irrational when they begin to struggle with the contradictions between the release of new versions of software and reusable components. The only way to make changes to the component so that these changes justify itself completely is to agree with its developer that your changes will be included in the next version. But this is only possible if the goals of your changes coincide with the developer's view on how its component should be developed.

Solution

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 created software product as new versions of the used components are released (in concert).

When making changes is unavoidable, you must use an insulating layer (see Vendor Lock-In antipattern from the Antipatterns of Software Architecture section). Use an insulating layer and other techniques to remove the dependence of the developed software from changes in the components used and from proprietary interfaces.

Exceptions

The antipattern “dead end” may be acceptable in test projects auxiliary to 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 enter the “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 a development workflow is closely tied to the functionality of this plugin. If, when updating the integration system, its API changes, you will have to make changes to the plugin.

Other antipatterns

Antipatterns of design

• Poltergeist
• Dead end