Over the years, we have built tiny up to large systems that provide a launching point for other applications. These solutions are built on the hard work and ingenuity of those that went before us. Therefore, we want to take advantage of that work and not have to reinvent the wheel. When we customize our solutions in a way that breaks our ability to continue to take advantage of a product, we have achieved the dead end antipattern.
Defining the Dead End AntiPattern
The simplest definition of this anti-pattern may be the best. [Click Here to See The Page]
“Direct modification of commercial software or reusable software creates significant maintenance burdens for a software system.“
In short, a dead end occurs when we customize the code of a vendor beyond where they will support it. Thus, you have voided the warranty and will not be able to take advantage of future upgrades, enhancements, and patches. You are now on your own.
It Is You, Not Them
The first item of note with the dead end antipattern is that this is a reflection on your choices. The vendor will be able to move ahead and make changes to their system. Likewise, you will be able to enhance your solution. However, you will not receive their updates and may have to replicate the features that would have been provided as part of being a customer. This antipattern is more about an increased workload than an impossible situation.
On the other hand, there might be critical upgrades a vendor provides that are critical to the long-term viability of your product. Operating system support is an example of this situation. The version of the software you are on when you make the dead-end choice might not support future OS versions. This situation occurs when you have new technologies such as we saw in PC OS advances during the nineties and early two thousand’s. When Windows XP came out, it might have made your Windows 95 software unusable. A simple upgrade would fix that, but you could be blocked by a dead end.
Design and Frameworks
The most common way to bump up against this antipattern is through frameworks. They are likely to be extended due to their nature. However, when you do so in an improper manner, you can stumble into a dead end. The solution is to build on top of vendor products and frameworks. Do not give in to the temptation to change core code just because it is available. There should also be abstraction layers in place, where applicable, to allow you to change the software on the other side of that layer. When you design a solution this way, you still will have an impact on changing the platform. However, it will be fixed by some mapping changes and not run you into a brick wall.
