(CategoryAntiPattern: This is a mini AntiPattern.)
Problem: A BoatAnchor is a piece of software or hardware that serves no useful purpose on the current project. Often, the BoatAnchor is a costly acquisition, which makes the purchase even more ironic. [Brown98] (See AntiPatternsBook)
A methodology or process can also be a BoatAnchor.
When I first graduated college, my job was to write printer drivers for a word processor. We had printers of all types. One model in particular, the Toshiba 3-in-1 printer was particularly bad. We decided that the 3 modes were BookEnd?, DoorStop? and BoatAnchor. -- DavidCorbin
doorstop, boatanchor, and paperweight are all names I have given machines. In another amusing story, I've seen JavaStations? literally used as doorstops.
Doesn't this malign boat anchors? Anyone who's spent time in a boat knows that an anchor is a very useful piece of equipment.
Yes, indeed, quite useful, as long as it's in the boat and tied to the right line. But what happens when you put it in the hallway by the front door of your house?
Good point. It reminds me that I'm not sailing which makes me grumpy.
The cliche itself upon which this pattern is based does not malign boat anchors. A boat anchor has one great purpose. The phrase "This makes a great boat anchor" means the the object is useless at its intended purpose and only its weight as anchorage seems positive. "Software as a boat anchor" is an oxymoron and makes poor usage of an old cliche since it makes a lousy boat anchor.
Ah... but do we not remember TheAlmightyThud?
See BearTrap?
A boat anchor that moors your boat during the storm, with the ability to pull it up and move on....ah darn AnalogyBreakdownAntiPattern! -- jim fuller
The phrase you are looking for is "Mooring Weight" rather than "Boat Anchor." A boat anchor is useful because of its shape; a mooring weight is useful because it is heavy.
A worse situation with a BoatAnchor is when the upper layers (i.e. management) are requesting it to be used somewhere in the project. The technical stuff is put in a position of not making angry the above mentioned upper layers (by simply discarding the BoatAnchor) and also to find solutions to integrate the BigBadThing?, with as little effort and bad consequences as possible, into the project. -- Sebastian Tiponut
Even worse is when the BoatAnchor is championed by a LeadArchitect? who is a) politically tied to the BoatAnchor (!), b) not smart enough to realize that the BoatAnchor is useless, but c) smart enough to detect any attempt by the team to isolate or otherwise not fully utilize the BoatAnchor. In other words, the BoatAnchor is prominently found on the UML diagrams, and he ensures that the boat sails at full steam, trailing the anchor behind.
Any resulting problems, like the boat sinking, are the developers' fault.
A BoatAnchor also can have a peculiar effect on all of the development cycle, leading to design or deployment options one would not think of in one's nightmare. This leads to very bad architectural/design/development measures and absurd deployments. Most of the time goes in trying to figure the BoatAnchor becouse with most of the things it is incompatible.