Blue Acorn iCi recently attended the UberConf in Denver, the ultimate java/agility event. We wanted to share our take on some of our favorite sessions. One session that stood out was about software development anti-patterns and how to prevent them. The session covered the basic concept, a few different patterns, and how to prevent/fix the issues related to five specific patterns. This post covers a few of the ones that weren’t represented during the session, but we felt are just as important. Be sure to look out for another post about a topic from UberConf coming soon!
One of the main aspects of software development is the ability to identify and utilize patterns. These patterns show up throughout all stages of development, from recognizing patterns while writing code to deciding the best architectural pattern based on customer requirements.
Patterns have a dark side as well.
Aptly named anti-patterns, it is just as important for good developers to be mindful of anti-patterns as it is for them to watch for patterns. Anti-patterns occur when a pattern directly hinders the development process by causing various issues (which specific issues will depend on the situation).
Where do anti-patterns come from?
Anti-patterns have been observed in many aspects of the development process and come in various forms. The most common source of anti-patterns is actually the use of outdated patterns, which are considered defective when they negatively affect the development process.
Becoming outdated can happen quickly due to the exponential growth and improvement of technology. Developers should keep up to date with the latest software technologies and patterns so their work does not suffer from using outdated or obsolete practices.
One of the best ways to identify an anti-pattern, ideally before it starts having a big impact, is to look for certain code patterns called code smells. These smells can be an indication of a bigger issue with the source code, but require more investigation to help you figure out the root of the cause.
There are also some non-code related issues that arise during development that can lead to additional stress and the persistence of anti-patterns. The main three that need to be watched out for are:
- Haste due to deadlines
- Apathy from other teammates
- Ignorance of some of the more prevalent anti-patterns
There are quite a few anti-patterns, which can be found on wikipedia or at Sourcemaking.com; however three of the more prevalent anti-patterns are the magic number, cargo cult programming, and gold plating.
Anti-Pattern 1: The Magic Number Theory
During any developer’s career they will likely have to look through older code, also known as software archaeology, which could have been written by a person who is no longer with that organization. Eventually, the developer will likely find hard-coded numbers that seem arbitrary because they have little to no context about where they came from or what they do.
That’s the basis for the magic number theory, since for all you know they might be “magic numbers.” It might have made sense at the time to just write them directly in the code, but later on they become difficult to work with and, if necessary, difficult to refactor.
Instead of hard coding them in we recommend creating a variable, usually a constant, to define what the value represents, even if it doesn’t seem necessary. Doing this will improve the readability of the code, allow for other developers to come in and change them if needed, and improve the ability to do a larger refactor later on,if necessary.
Anti-Pattern 2: Cargo Cult Programming
Cargo cult programming is another common issue that plagues software development. When a developer uses code that they don’t fully understand, such as objects, methods, or design patterns, it’s considered Cargo Cult Programming. This usually becomes more prevalent the bigger a code base gets, since that makes it more likely the developer will add code without knowing how it works.
When a developer uses code they don’t fully understand they can introduce bugs or add more than what is necessary to fix an issue. Newer people on a project are typically more prone to this, as they may see similar code elsewhere without knowing the exact purpose of each line. The responsibility of avoiding this problem and the issues it causes rests with the developers, who should look up any parts of code they are unfamiliar with to avoid any mistakes.
This is also an important practice for code reviews, since you shouldn’t pass code that you do not completely understand.
Anti-Pattern 3: Gold Plating
The final anti-pattern we want to touch on is gold plating, which can occur after a developer has finished up a requirement but then sees room for more improvements or enhancements that they think the customer might want.
Adding New Functionality
This does not sound like a big issue, but if the improvement proves more complex than the developer thought it can eat up time. There is also a possibility of the customer seeing the added functionality and then deciding that it is not what they are really looking for, which means all the time spent on it was wasted.
However, if the extra functionality is viewed as important, it might be best to work on it immediately. Since this is more situational than the other two, there isn’t any one perfect solution. The best place to start for new functionality is by talking to the customer, since they decide whether or not it gets worked on; this way no work will be lost.
Creating Tech Debt
If a developer is working on something and realizes there is an issue with the existing code, that can create tech debt. These tasks are usually found when a developer realizes how to optimize or modify existing code to improve it after more development work has been done. In this scenario, try time boxing your work so that if it becomes too much effort for that particular moment then you can create a ticket for it to be addressed later.
Preventing Anti-Patterns: Avoiding Development Problems
Software development is a field where we are constantly looking for patterns, but ignoring anti-patterns can almost be worse than choosing less optimal design patterns.
If developers can identify these issues early on, it can save time, prevent frustration, and reduce refactoring in the long run. But recognizing an anti-pattern during development can be difficult, since there are usually other issues with the development process that can distract developers from recognizing the signs.
It’s helpful to glance at a list of anti-patterns every few weeks and to check if any have started manifesting themselves. Getting familiar with at least a few will allow you to identify them more easily in the future.