Boat anchor

In amateur radio and computing, a boat anchor or boatanchor is something obsolete, useless, and cumbersome – so-called because metaphorically its only productive use is to be thrown into the water as a boat mooring. Terms such as brick, doorstop, and paperweight are similar.

Amateur radio

In amateur radio, a boat anchor or boatanchor is an old piece of radio equipment. It is usually used in reference to large, heavy radio equipment of earlier decades that used tubes. In this context boat anchors are often prized by their owners and their strengths (e.g. immunity to EMP) emphasised, even if newer equipment is more capable.

An early use of the term appeared in a 1956 issue of CQ Amateur Radio Magazine. The magazine published a letter from a reader seeking "schematics or conversion data" for a war surplus Wireless Set No. 19 MK II transceiver in order to modify it for use on the amateur bands. The editor added this reply: "The only conversion we seem to have on the files here at CQ calls for 100 feet of 1 inch Manila line, one end of which is to be tied securely around the MK II Transceiver. This then converts the unit into a fine anchor for a small boat. If any readers have better conversions we will be glad to hear about them. — Ed."

The editor's use of the term generated some reader interest, and in February 1957, CQ published a follow-up story that included photos.

Computers

The metaphor transfers directly from old radios to old computers. It also has been extended to refer to relic software.

Hardware

Early computers were physically large and heavy devices. As computers became more compact, the term boat anchor became popular among users to signify that the earlier, larger computer gear was obsolete and no longer useful.

Software

The term boat anchor has been extended to software development to refer to an anti-pattern of unused source code or other components left in a program's codebase, introducing unnecessary complexity and maintenance.

Boat anchors in software are liable to exacerbate memory usage, file size, compile times, and security risks. Additionally, they may create unnecessary cognitive load for programmers to identify code that does not execute at runtime, and increase risk of accidental restoration of deprecated code by linking to working code.

It is recommended to remove boat anchors from a code base or to isolate them for later reference if necessary, allowing the compiler to exclude the unused code or components. When making such modifications, programmers use version control retain a history of the codebase, in case the code may be restored for later avail.

For lines of code, instead of outright removal, a programmer may alternatively disable them by commenting them out, which signals to the compiler to ignore those lines, and visually signifies to other programmers that the code is not in use but worth preservation.

For components such as libraries, programmers may distinguish included components with a build system by using configuration files or command line arguments. For example, a game developer may remove unused parts of their game engine from the final build of the game, such as removing unused 3D graphics from a game that only uses 2D graphics.