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 only correction I would add to this definition is that this has more reasons than simply developer belief.  Sometimes there are political reasons for a boat anchor or even momentum that makes replacing it difficult.

Cut…It…Out.

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.

Rob Broadhead

Rob is a founder of, and frequent contributor to, Develpreneur. This includes the Building Better Developers podcast. He is also a lifetime learner as a developer, designer, and manager of software solutions. Rob is the founder of RB Consulting and has managed to author a book about his family experiences and a few about becoming a better developer. In his free time, he stays busy raising five children (although they have grown into adults). When he has a chance to breathe, he is on the ice playing hockey to relax or working on his ballroom dance skills.

Leave a Reply