Sometimes ideas that are good at one time become horrible later on. This is one of many ways to get stuck in the boat anchor anti-pattern. It is a situation that is well-described by the anti-pattern name. We find ourselves dragging along a product or code that is doing little other than slowing us down.
Defining the Continuous Obsolescence Anti-Pattern
Although it may be bad form, I found a good definition of this anti-pattern on a site covering the anti-pattern much like we are here. [Click Here to See The Page]
“A Boat Anchor is a programming anti-pattern that occurs when a part of a system is kept in that system despite it no longer having any use. Generally this is because of developer belief (or prior experience) that they’ll need it later. This belief is almost always wrong.“The fastest way to eliminate the drag from an anchor is to cut the rope tying you to it. However, that is not always a feasible solution. There are political reasons to keep that anchor around (eg. the CEO loves the boat anchor product) or we might have just enough usefulness left in the anchor to keep us from jettisoning it.
Nevertheless, our best solution is going to be the simplest one. When you find yourself dealing with this anti-pattern the best approach is to design it out of the picture ASAP. By definition, the cost of keeping this thing around is growing over time. It is a bad investment so do not keep throwing good resources away with the bad.
Surprise! It’s a Boat Anchor
The scary thing about the boat anchor is that it does not always look like one early on. That is the lure that gets us into this situation. There is a good solution available that we embrace and down the road, it becomes aged and something that needs to be replaced. This can happen with any framework or product. Therefore, we can avoid this anti-pattern by designing our solutions with ways to avoid vendor lock-in. Look into things like loose coupling and pluggable patterns to leave yourself an out when good products go bad.