In part one of this series, we talked about how to initially organize your code base, and what kind of pitfalls can show up if you don’t take into account things like business logic.  This creates a structure that is easy enough to comprehend, and developers can then mentally map to your product quickly and easily.  However, code bases change over time, usually because the organizations–and the people in them–change over time as well.  This introduces issues in the code base that we’ll refer to as anti-patterns.

What is an Anti-pattern?

Going back to our banking application from part 1, for example, we discussed how business logic would ‘live’ in the application if a user got a car loan or had a lot of debt.  Chances are, if we started off with MVC, we’d put most of the logic in the Controller.  This could open the door to what’s called an anti-pattern — that is, a pattern in the code base which is a detriment to good development.  This particular anti-pattern is called the ‘magic controller’ or the ‘god object’ because we load the controller object up with all sorts of code and functionality and it becomes bloated (think of a single file of code with five or ten thousand lines!), and therefore, hard to maintain.
Other anti-patterns can be common and very simple mistakes like:

  • repeating different pieces of logic in different parts of the code base
  • not indenting the code correctly
  • not using meaningful variable names
  • rewriting a library function that already exists (a modern-day version of ‘reinventing the wheel’)

Why Anti-patterns Get into Production Code

Shifting Priorities

This can happen because of shifting priorities.  Your developers may be on a tight deadline to deliver a feature and think to themselves, “I’ll just ship it this way quickly now, and come back to fix it later” but later usually never comes, as they are put on another feature which is also assigned a high priority.  And their bad habit of putting shortcuts in the code may continue.

Developer-specific Habits

This can also happen when different people come on board.  Every developer is self-disciplined; but each developer may have a favorite shortcut, or a bad habit, that they cultivate in their code reviews and fixes.  Over time, this bad habit may appear as one of the anti-patterns listed above, or worse.

Lack of or Adherence to Structure

Finally, this can happen because of a lack of good structure, or the development team failing to adhere to good structure.  While we covered this in part one, it’s important to keep in mind that you have to continue to adhere to a given structure, after initially choosing it.  The reverse can also be true; if you have a structure which doesn’t quite fit for the purpose of the product (like our MVC banking example), it is sometimes necessary to adopt a new overall structure in the code base.

How to Prevent Anti-patterns

So how are ways we can mitigate these three causes of anti-patterns, so that code quality in software development is still high, even after the 20th, 50th, 100th sprint?

1. Seek feedback from others.

Developers, when working alone, can sometimes get ‘tunnel vision’ about a certain solution, feature, or bug fix.  It’s always a good idea to seek out and discuss problems when they arise.  This can be facilitated in Agile processes with regular code review, or pair programming.

2. Use tools which can look for red flags.

It is a great idea to automate parts of code quality by using a code formatting tool in your IDE of choice, or better yet, using a separate tool such as a ‘linter’ to examine the code to pick out possible weaknesses or other troublesome areas.

3. Be aware of common anti-patterns.

Make sure your workforce is able to recognize common shortcuts and anti-patterns that will result in problems later.  Often this is a skill that comes with programming experience, but you can also educate your developers to look for design patterns, and not anti-patterns.  Often educators will refer to a seminal work on Design Patterns written by four academics colloquially referred to as the Gang of Four: Gamma, Helm, Johnson and Vlissides.  Using this text as a reference will lead to success.


In part one, we talked about picking the best structure to start with on a project.  In practice, over time, we need to find ways to keep the code quality high so that we can continue on a predictable schedule, generating new features and tools while keeping the bug count low.  Using the above methods to weed out the anti-patterns in your code are the best way to make sure that happens.

However, there may come a time when your methods can’t stop an issue from causing problems in your code base.  How can we deal with that?  This is the topic for next week’s column: Crisis Management in Software Development.

References for more information:


To learn more, please contact Hillside Group.