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 solution is precisely what you think it is...
...OK maybe not precisely what you think. Let's think bigger.
...Now we're talking.
In the real world, the solution to the Boat Anchor anti-pattern (other than a badass chainsaw) comes down to five letters: YAGNI.
- Name: Boat Anchor
- Summary: A part of a project which is kept in said project despite it not being used.
- Type: Programming
- Common?: NOT ON MY WATCH! (revs chainsaw)
Tell Me a Story!
My team recently merged with another team here at my employer. In the process of doing so, I became lead developer for the combined team. One of my jobs as the lead was to come up with team coding standards, including naming, spacing, structure, etc.
In several in the combined team's projects (including ones I was in charge of before the merger) were classes, sometimes entire sections, of code that still existed, still ran, but were never used within their respective codebases. These extraneous classes just kinda existed, hung out, chilled. But like your stoner friend, they didn't actually do anything.
What was interesting about each of these anchors was that the developers responsible for them generally had the same reasoning:
"But what if I need this later?"
To be fair to them, in more than half of those projects we had had situations where we removed a piece of code we were told to remove and then had to add back at a later date. My teammates weren't saving code because it was fun; they were saving code because it might save them.
But in my case, I had a problem. I could not look at these extra classes and know if they were being used. Maybe I could guess, but I couldn't really know. I had to ask someone about each one of them, and occasionally it took a bit to track down someone who could answer. There was no clear evidence when something was or was not being utilized just from reading the code.
I'm an extreme deletionist. The best code is no code. You can guess what my response to "But what if I need this later?" would be.
"You probably won't."
Strategies to Solve
The Boat Anchor is one of the few anti-patterns that has a clear, concise solution, one that has been known for decades. A solution called YAGNI.
YAGNI is an acronym for "You Ain't Gonna Need It" and it's one of the oldest programming adages. Longtime readers will know that I'm a huge fan of this acronym, because in my opinion it solves one of the primary issues facing code: bloat.
Look, programming is a messy endeavor. We strive to create elegant, concise programs, but they have to work first, and sometimes we don't get the time we need to make things nice in the code base. We are messy artists, toddlers with a crayon, permanent amateurs. We make the mess. YAGNI helps us clean it up.
If you can prove some piece of code is a Boat Anchor, don't think, don't question, just delete it. Period. You ain't gonna need it! Just like it's so much nicer to have a clean room, it's so much nicer to have clean code.
(If you absolutely have to keep it, at least keep it somewhere else, not commented out in the code itself. Some other part of the project, possibly in your source control system. Trust me, future you will thank you for that.)
If there's any doubt, throw it out! Yes, now!
The Boat Anchor is a piece of a software project that is kept even though it is not used. There is absolutely no reason why you would ever want such a thing in your project. Remember YAGNI, and delete them all! Yes, even that one.
Did you find an example of a boat anchor in one of your projects? Or, gasp, a boat anchor that actually needed to be preserved? Do you have a badass chainsaw? I'd like to know about it (particularly that third one). Tell me about it in the comments! Or else head on back to the series index page to see some more anti-patterns.