Software Development Anti-Patterns

All software developers have participated in one or more software products and have all faced various problems related to writing code, some to software architecture, and others relate to how software projects are managed; which have caused negative consequences on the project. As a Scrum Master, I believe it is important to understand these anti-patterns and learn how to deal with them to avoid affecting our projects negatively. This article presents different types of software development anti-patterns which commonly occur in software projects; affecting project performance. The article also explains why each anti pattern happens and possible ways of dealing with them to avoid their negative consequences on the project. This information in this article was based on the Software Product Management Specialization in Coursera.

Common General Anti-patterns

1] Analysis paralysis

Analysis paralysis usually happens when your development team gets stuck in the specification phase of your project. Clients or product managers can get stuck trying to fully analyze the product requirements upfront, and can't decide on a direction for the product. Until that analysis is perfected. The problem here is that instead of getting things done you end up sitting around waiting for more information before making progress. This isn't in the spirit of agile. And you should certainly avoid it as much as possible.

The best way to avoid this as a software product manager, is to run an agile project with incremental releases. If you don't know everything at the start of your project, that's okay. You don't have to know everything up front, because you leave room for flexibility and change throughout the project.

2] Putting the cart before the horse

Another anti-pattern is called putting the cart before the horse. The definition of putting the cart before the horse in software product management is very much the same. Putting the cart before the horse refers to placing too much emphasis on a part of the project that should be done later. A good example of this is when programmers are pulled from the development of a critical feature for one that isn't required at the moment.

Accordingly, the best way to handle this is focusing on clearly prioritizing the work required for the project to avoid delaying a critical feature.

3] Groupthink

Groupthink is an anti-pattern that can cripple a software project. A great example of groupthink in action, is when a group of developers collaborate to design a product's architecture. If you've ever been a part of such a group, you may have noticed that ideas from one or two voices can dominate a meeting. The other, less vocal developers remain quiet in order to avoid conflict. This can lead to a poor product.

One way to avoid groupthink is to generate solutions to problems silently. Lean software development solves the issue by having the team separate into multiple groups, responsible for imagining their own solutions. Instead of having teams break off into smaller groups, let individuals come up with their own solutions on paper, no talking. Then, everyone comes back together and the team can discuss each person's ideas in turn. This prevents one or two people from dominating group discussions and gives all developers equal chances to share their proposals.

Team Anti-patterns

1] Working in silos

Organizations are often split into small groups for different project needs. Although separate groups can often get work done efficiently, it also makes it easy for these groups to lose touch. When this happens, when a team loses touch with other teams, we call this working in silos. Silos are poisonous to software development organizations. They represent a lack of communication among the organization. This makes it easy for the company to lose a unified image and for counterproductive management strategies to take hold. Instead of developers collaborating openly with other teams, they develop features in a vacuum.

One of the best is by reducing the amount of management in the organization. If your organization has a relatively flat management structure, you can avoid a lot of office bureaucracy, and get people talking directly, ideally face-to-face. Another way to avoid silos, is to encourage a positive atmosphere around inter-team communication within the organization.

2] Vendor lock-in

Vendor lock-in happens when a development team creates a product around a single technology solution or vendor and depends heavily on it. What happens in cases of vendor lock-in, is the development team unwittingly causes their product to rely on one technology as they go into the future. If one day the technology can't cover what they need, that causes an inability to adapt to change.

One way to avoid vendor lock-in is to really do your research before committing to a technology or solution. It may seem like a trivial decision at the time, but without the proper information, it can be easy to get trapped into a bad situation.

3] Over-engineering

Over-engineering refers to the practice of creating a product that is more complex than it needs to be. For example, it happens when a development team packs the user interface with a lot of needless or speculative features. This can turn a perfectly functional product into a bloated one with too many extra features that may be confusing to use or even completely unusable.

The solution is pretty simple. Stop working when the product functions well. Those fancy extra features probably don't need to be added.

3] Gold-plating

Gold-plating refers to the effort put into a project to a point of diminishing returns. On nearly all software projects there is a point at which any extra effort that you put into a feature does not really contribute to the value of the product. Gold-plating is usually a result of the software development team putting in extra features in order to impress the client.

The solution is pretty simple. Stop working when the product functions well. If you really think they do need to be added, try to establish a vetting process for new features with your client.

Development Anti-patterns

Development anti-patterns focus on management practices that make it difficult for developers to do development work, because they're so focused on doing other things. Therefore, agile software development focuses on working software over comprehensive documentation.

1] Viewgraph Engineering

Focusing on comprehensive documentation is an example of an anti-pattern, called Viewgraph Engineering. Like gold plating, this is a result of unfocused work, or not working on important, high-value things. Viewgraph engineering is when developers kill their productivity by spending more time building presentations, reports, and documentation, instead of developing code. This often happens at organizations with vertical management structure, organizations where in order to prove a concept, a developer must fully analyze its potential before going forward. It's a lot like analysis paralysis but at an organizational level.

The best solution is to remove barriers blocking your developers from developing the product. Often, the time spent creating all the necessary reports and presentations would be enough to create a basic product prototype. The prototype is often more informative than any report can be and comes with a bonus of having working software off of which successive products can be built.

2] Fire drill

A Fire drill is what happened when developers do too little work throughout the majority of the project and then all of a sudden need to make a big push toward the end. This can be a result of lackadaisical management or the impact of a developers themselves wasting time. It can also occur when expectations are not properly set with the client.

3] Heroic

Fire drills often lead to another anti-pattern, called Heroics. This is a tongue in cheek way of describing what happens when your project relies on one developer's nearly superhuman technical skills to get the project done. People become reliant on that person to get the work done, even outside of the big push at the end.

The best way to avoid this, is to establish expectations with your client early in your project and follow an agile software development practice. You could implement time boxing and other planning techniques that give your developers the structure they need to get things done on time.

4] Death March

What about when management struggles to get the development team to believe in the work they're doing? This is called a Death March. Everyone on the development team knows that the project is destined for failure, but everyone continues to build a project anyway, out of obligation. Imagine the terrible consequences of this. Some causes for how this might arise, are management forcing the project on a development team for financial reasons. Or management might be stubborn and in denial of the inevitable failure.

Individual Managers Anti-patterns

1] Micromanagement

Micromanagement is so common it's almost a buzz word. It's a very real issue that many organizations face. Micromanagement is what happens when someone in a management position tends to want to be involved in every little detail of a project. They're usually the people who ask to be CCed on every email coming to and from their team and feel the need to offer their opinion on every decision made, or perspective shared in the workplace. Micro managers are the people who want to know where the developers are at every minute and what they're doing. In essence micromanagement is about control. Micromanagement is usually a symptom of the manager's own fears, insecurities, and stresses.

The solution for micromanagement has to come from the micro manager themselves. Like any of these anti patterns at an individual level, there's no quick or easy fix. To really address this issue, the manager who exhibits this behavior must be willing to admit that their behavior has a negative impact on the team, and take steps toward improvement.

2] Seagull Manager

an anti pattern that's closely related to the micro manager is the seagull manager. The someone you don't see until a problem arises at which point the manager flies in makes a lot of noise, dumps on everyone, then flies out. To quote Ken Blanchard a writer in the field, it's funny, but it happens. These are a different breed of manager from the micro manager. And their motivations for their behavior are very different. A seagull manager can cause just as much commotion and stress within the development team as a micro manager. They may even inadvertently become the cause of a project turning into a fire drill project.

Individual Developers Anti-patterns

1] Loose cannon

A loose cannon is a person who makes significant project decisions without consulting the rest of the team. They might also cause problems in their workplace by asserting their opinions on nearly any topic. Instead of helping to make progress, the loose cannon often impedes it. By raising small concerns and questioning every little thing. If the person makes their point often enough, others in the group will often concede just to avoid making a fuss. When a loose canon makes decisions without consulting the group, they can create more work for other team members, and cause major headaches for everyone involved. A loose cannon in that case can tear through a development team and quickly derail productivity. As difficult as it can be, it's important to deal with the behavior of a loose cannon as quickly as possible.

The solution often depends on why the individual is acting the way they are. Sometimes the loose cannon just wants to cause trouble. And sometimes they want to prove their own worth. An ideal solution to the loose cannon is to try and get an individual to see their own behavior as destructive and make steps to change it.

2] Intellectual violence

Intellectual violence is as much about the developer's inner world as any of the other anti-patterns I've described. Intellectual Violence can be used by loose cannons, making meetings unbearable. Intellectual Violence is a situation where a person uses their advanced knowledge in an area to intimidate others. This might manifest itself as a developer talking down to team members when they ask questions about a technology they aren't familiar with. As you might imagine, behaviors like this can cause team members to feel unappreciated and unimportant.

To address an intellectual violence problem, try talking to the individual in private. Ask them to reflect on how their behavior affects others on the team. Like the loose cannon it's important to deal with this issue early so that it doesn't have a lasting impact on your team and your project.

References

"Anti-pattern - Wikipedia, the free encyclopedia." 2011. 5 Jan. 2016 <https://en.wikipedia.org/wiki/Anti-pattern>

"Classic Mistakes Enumerated - Steve McConnell." 2003. 5 Jan. 2016 <https://www.stevemcconnell.com/rdenum.htm>

"Project Management AntiPatterns." 2012. 5 Jan. 2016 <https://sourcemaking.com/antipatterns/software-project-management-antipatterns>