Design Anti-Pattern: Boat-Anchor Method

By Mohamed BEN LAKBIR

SWEN 656 9040 Advanced Software Engineering
April 7th, 2022
 I – DESCRIPTION
A – What is design Anti-Pattern?
If a design pattern is a repeatable architectural solution for common problems or situations that arise when
designing a software application, anti-pattern design is the opposite. Yet, a design pattern becomes an anti-
pattern when it causes more complications than it solves (bad design). An anti-pattern is a bad approach to
solving common programing difficulties. It is designed for the developer to understand issues with bad solutions
(NYSIA, 2005, p. 4). Anti-pattern takes place if a manager or developer is not skilled enough or applying a
perfectly good design pattern in the wrong context (NYSIA, 2005, p. 8).

B – Anti-Patterns’ categories
Based on the approach it intents to prevent, anti-patterns are divided into numerous categories:
• Organizational anti-patterns identify bad general company wide behavior.
• Project management anti-patterns pinpoint what can run a project against the wall?
• Analysis anti-patterns detect analysis and reporting issues.
• Software design anti-patterns ascertain bad patterns used in architecture.
• Object-oriented design anti-patterns recognize wrong implementation in detailed design.
• Programming anti-patterns classify bad low-level coding practices.
• Methodological anti-patterns indicate bad coding behavior.
• Configuration management anti-patterns signify bad relationship between components.
• Branching and Merging anti-patterns identify difficult integration situations.
(ColoreOfCode, 2020).
 I – DESCRIPTION

C – Boat Anchor Anti-Pattern

Generally, a boat anchor is a metaphor used to describe a piece of hardware or software serving no
useful purpose on a project and weighing down its success. In the software realm, a boat anchor can refer
to a standalone software product or a chunk of code (Gilliland, n.d.). Boat Anchor belongs to
programming anti-patterns category. It takes place when a part of a system is kept despite it no longer
has any use. In a project, Boat Anchor signifies low-level coding practices. Habitually, it is due to the
belief – based on prior experience – that the code might be needed in the future (Broadhead, 2019).
Obsolete or not-in-use code that is still a part of the code base is a boat anchor. Retaining outdated
functionality in the system is an invitation to an invisible risk. Although the unused modules, classes or
any other structs seem highly unlikely to cause a problem, they still can at any moment (Mehra, 2021).
 II – TYPICAL SCENARIOS

A – Boat Anchor occurrence

In software point of view, Boat Anchor design anti-pattern takes place when the code is left in a system in
the following circumstances:
• In case the code might be needed in the future.
• The reference to a particular function is removed and eventually nothing is calling it. Then the function is left
stranded.
• For some reason, modular level variables are written and then not used.
(Zablocki, 2014, 3:33).

B – Boat Anchor identification

Boat anchors are properly easy to locate in the following cases:
• If the developers find themselves spending an extraordinary amount of time reworking code to “fit” an
external software product.
• If there is a software product included in the compiling or building process of the project, but doesn’t
introduce any benefit to the process or the output.
• Methods or functions within software code that do not have any callers are likely boat anchors.
(Gilliland, n.d.).
 II – TYPICAL SCENARIOS

C – Boat Anchor consequences

• The code becomes longer and hard to read due to unnecessary parts.
• The code becomes hard to maintain due to uncertainty of what should be checked in regression testing.
• The code becomes hard to debug. It is difficult to know which variables and methods are relevant still.
• The code becomes vulnerable to errors because developers could call obsolete code that has no use anymore.
(Zablocki, 2014, 4:47).
According to Broadhead (2019);
“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.”.

D – Boat Anchor prevention

• When written code is not being used then delete it. If removing it is not an option then at least comment it out to visually signify that it
is not being used.
• Integrate a source (version) control software into development environment. When code has been changed, previous version can be
examined to analyze changes or revert back to old methods.
• Obsolete code, even if it may be required in future, should be kept in a separate repository from where it can be referred to or reinstituted
when required.
(Zablocki, 2014, 6:33).
 III – SAMPLE USAGE CODE
For introduced example, assume there is a method called, “editAccount(Account account)”. Its purpose is to edit an account for a
local gift shop (GiftShop class). Somewhere along the line, a developer decides to write another method “updateAccount(Account
account)” that serves the same purpose, but with a different approach. The developer changes all calls to the former method to reflect the new
method, but leaves the old method in place just in case someone needs to refer to it in the future (Gilliland, n.d.).

// original method, editAccount(Account account)

public void editAccount(Account account) throws FileNotFoundException, IOException {
File fileName = new File(directory + account.getAccountNo());
BufferedReader reader = new BufferedReader(new FileReader(fileName));
while (line != null) {
if (line.contains("comp")) {
if (line.contains("company_addr")) {
tempStrChanges = line.substring(line.indexOf("company_addr>") + 13, line.indexOf(" -"));
tempCityChanges = line.substring(line.indexOf("- ") + 2, line.indexOf(","));
tempStChanges = line.substring(line.indexOf(",") + 2, line.indexOf(",") + 4);
tempZipChanges = line.substring(line.length() - 20, line.length() - 15);
tempCompAddr = new Address(tempStr, tempCity, tempSt, tempZip);
}
if (line.contains("comp_email")) {
tempCompEmailChanges = line.substring(line.indexOf("comp_email>") + 11,
line.indexOf("</comp_email>"));
}
}
line = reader.readLine();
}
reader.close();
fileName.delete();
}
 III – SAMPLE USAGE CODE
// boat anchor is the method the developer should have been working with
// this updateAccount(Account account) method is similar to the previous edit method
public void updateAccount(Account account) throws FileNotFoundException, IOException {
File fileName = new File(directory + account.getAccountNo());
BufferedReader reader = new BufferedReader(new FileReader(fileName));
if (!tempStr.equals(tempStrChanges) || !tempCity.equals(tempCityChanges) || !
tempSt.equals(tempStChanges) || !tempZip.equals(tempZipChanges) || !
tempCompEmail.equals(tempCompEmailChanges)) {
hasChanged = 1;
}
if (hasChanged == 1) {
tempCompAddr.setStreet(tempStr);
tempCompAddr.setCity(tempCity);
tempCompAddr.setState(tempSt);
tempCompAddr.setZip(tempZip);
Company newCo = new Company(tempCompAddr, tempCompID, tempCompName, tempCompEmail);
editedAccount = new Account(newCo);
PrintWriter out = new PrintWriter(fileName);
// close the file
out.close();
}
}
  This second method, boat anchor, is similar to the old one. It is the method the developer should have been working with. For some
reason, another developer is assigned to fixing a bug reported by a user. The output is not correct and the developer must figure out the reason.
The developer looks through the code base and finds the “editAccount()” method and begins to make changes to this code in an effort to
address the issue. Nothing works, nothing changes. The developer has now wasted valuable time without success before realizing the code is
never executed. As a result, this trap is not part of the problem at all (Gilliland, n.d.).
IV – UML DIAGRAMS
 IV – UML DIAGRAMS

Explanation
As shown in the UML diagram, there are two methods – “editAccount(Account account)” and
“updateAccount(Account account)” – serving the same purpose with different approaches for a local gift shop
(GiftShop class). In this – studied – case, the best approach is going to be the simplest one. When developers
find themselves dealing with this anti-pattern, the best solution is to take it out of the picture immediately.
The cost of keeping this thing around is growing over time. It is a bad investment so keep throwing good
resources away with the bad should not happen (Broadhead, 2019). If the developer leaves the extraneous
method in place just in case someone needs to refer to it in the future, it is a Boat Anchor. It could lead to
difficulty to read the code, hard debugging, unnecessary maintenance and testing, or call an obsolete code. This
pattern is one of the few anti-patterns that has a clear, concise solution, one that has been known for decades.
YAGNI – "You Ain't Gonna Need It" – as solution is one of the oldest programming adages (Jones, 2018). To
appropriately design the system, the Boat Anchor – “updateAccount(Account account)” – must be removed
from “GiftShop” class.
IV – UML DIAGRAMS
 V – PROS & CONS

A – Boat Anchor detection

• Boat anchors are properly easy to identify. If the developers find themselves spending an extraordinary
amount of time reworking code to “fit” an external software product, it is likely a boat anchor.
• If there is a software product included in the compiling or building process of the project, but doesn’t
introduce any benefit to the process or the output, it is likely a boat anchor.
• Methods or functions within software code that do not have any callers are likely boat anchors.
(Gilliland, n.d.).
 
B – How to avoid Boat Anchor
To prevent introducing a boat anchor from software, there are two recommendations:
• Development teams and managers should employ an in-depth, all-inclusive method of researching
potential software suites before it is purchased. All significant team members should participate in the
assessment to make sure acquired software will be useful.
• Unattended code within software should be deleted or removed (i.e. stored externally or deleted) to avoid
confusion and increased compile times.
(Gilliland, n.d.).
 V – PROS & CONS

C – Boat Anchor penalties

For been a bad software design pattern, Boat-Anchor is more likely to:
 
• Bloat the code base.
• Mislead developers during debugging. They may end up working the wrong code before they eventually
get to know that it is not related to the problem they are solving at all.
• Be unknowingly referred to and used in the active code leading to some unwarranted behavior.
• Influence the system’s performance by starting up some scheduled or queueing tasks when they are no
longer needed.
• Increase the compilation time.
• Use valuable system resources by any active singletons or spring beans.
• Weigh down the project and keep it from moving forward quickly leading to missed dead line.
• Add more costs to the project budget.
(Mehra, 2021).
 References

Broadhead, R. (2019, May 17). The boat anchor anti-pattern. Retrieved May 26, 2022, from
https://develpreneur.com/the-boat-anchor-anti-pattern/
ColorOfCode. (2020, March 09). Anti-Patterns. Retrieved May 25, 2022, from
https://color-of-code.de/patterns/anti-patterns
Gilliland, C. (n.d.). Boat anchor anti pattern. SWEN 656 – 9040 Advanced Software Design &
Implementation.
Jones, M. (2018). Boat Anchor - The daily software Anti-Pattern. Retrieved May 24, 2022, from
https://exceptionnotfound.net/boat-anchor-the-daily-software-anti-pattern/
Mehra, L. (2021). Software design patterns for java developers | Chapter 14 - Beyond design patterns |
Anti-patterns. Retrieved May 27, 2022, from
https://library-books24x7-com.ezproxy.umgc.edu/assetviewer.aspx?
bookid=158351&chunkid=199463621&noteMenuToggle=0&hitSectionMenuToggle=0&leftMenuState=1
NYSIA. (2005, December 6). Recognizing and understanding anti patterns in java application
development. Retrieved May 23, 2022, from https://redlich.net/pdf/presentations/nysia-jug/anti-
patterns.pdf
Zablocki, J. J. (2014, Mars 29). Anti-Design pattern boat anchor [video]. Retrieved May 20, 2022, from
https://www.youtube.com/watch?v=3Id6Q0qH1XU