Two Antipatterns Make a Pattern Do Not

In Chinese philosophy, if there is a Ying, there is a Yang. In mathematics, if you multiple two negatives, you get a positive.

Unfortunately, two antipatterns do not make a pattern. My conclusion is that is what a team of developers had in mind, while working on a prior project.

Antipatterns

What are antipatterns? Wikipedia defines an antipattern as:

A common response to a recurring problem that is usually ineffective and risks being highly counterproductive.

The term was first brought to light by Andrew Koenig, while reading the book Design Patterns, which is available on Amazon.com and was a helpful read that I enjoyed in the late 1990s.

Antipatterns in Programming

Below are some common examples of antipatterns that can find their way into a production code stream if not caught during the pull-request approval process:

• Boat Anchor - leaving functionality in the code that serves no purpose.

• Busy Waiting - intentionally introducing a wait cycle in the code to allow another process to complete (impacting CPU utilization).

• Hard Code - embedding data directly into the code stream.

• Lasagna Code - implementing a structure which contains an unnecessary number of inheritance layers.

• Magic Numbers - including numeric values into the code stream whose rationale is hard to understand.

• Spaghetti Code - utilizing a structure that is difficult to comprehend and follow.

More antipattern examples can be found here.

My Example

While working on a project, I was placed in the pull-request approval process for code that was intended to be deployed to the `develop` branch and then to `master`. The team had utilized their own QA resources and had performed the necessary testing in their existing feature branch. Basically, the review was going to be the final step in getting this new feature into the hands of the end-user.

When I looked at the code, the first thing that caught my attention was the size and design of what appeared to be the main object of the feature. Looking through the class and all of the functionality inherit within, I saw this functionality to be what is called a "God object."

A God object is an anti-pattern. Instead of following the design approach of separating code into smaller problems, using a divide and conquer strategy, everything — I mean everything — was contained within the single class. The code under my review took in a request and it knew how to cover everything without the assistance of any other object or class.

As I continued to review the code, it was clear there was a lack of understanding behind some of the logic that was in place. With a couple Google searches, I realized what I referred to as Stack Overflow Driven Development was at play here. At the time, the project was using a framework that was new and did not have a large pool of developers to utilize. As a result, the copied code was yielding the *right* answer, but with an incorrect approach. From my view, this was adaptation of another antipattern, referred to as either "cargo cult programming" or "shotgun debugging."

With two antipatterns in place that needed to be resolved, the team was not happy to hear that the already-tested code branch was not approved. I also included an employee at the client, who would ultimately be supporting the code, as an additional reviewer of the request. While my direction and recommendations were as constructive as possible, the additional reviewer wasn't as nice.

Out of this I relearned a lesson I always try to keep in mind when developing features and functionality. I simply ask myself "would I want to support the code I am asking to be deployed?" If this answer is no, more work needs to be done.

Conclusion

While mathematicians realized that a negative number can be multiplied by another negative number to achieve a positive number, antipatterns do not follow the same logic pattern.

Adding more antipatterns only introduces more challenges in the code stream, which are not instantly resolved once an additional antipattern is added. Instead, time is needed to refactor and redesign each challenge that was introduced and labeled as an antipattern.

The key is to have an understanding of antipatterns, not only as a developer, but as a peer reviewer looking for provide constructive feedback to code wanting to be injected into the production code stream. This is a team effort, as even experienced developers can find themselves unintentionally introducing an antipattern.

Have a really great day!