How to Eliminate Anti-Patterns in Software Development?

A software product developer uses public variables in classes, instead of using properties. He keeps throwing wrong exceptions, and takes bool for a convention, instead of a real type. That’s the definition of software engineering madness – doing something repeatedly, expecting different results. Anti-patterns wreck software projects. Take a look at our guide, don’t be Disney’s, Wreck-It Ralph!

For those of you unfamiliar with the movie – Wreck-It Ralph is a character from an old and forgotten arcade video game. He’s a very loveable character but everything he touches turns into dust. Anti-patterns in software product development work similarly. They have repeatedly performed practices in software development (software architecture, design and project management) that look good on paper but in reality derail the project. By providing a list of the most used bad practices, we hope to propagate the quality mindset. After all, the work of Quality Assurance Engineer is like firefighter’s – in both cases we wish them the least amounts of work possible.

Anti-patterns in software product development

Positions on the list have funny names but most if not all of them are dangerous and sooner or later will have devastating results for your code quality.

Programming anti-patterns

• Probably the best example of this behavior is the ‘golden hammer’ rule. Once a developer learns something difficult, he’s so proud of himself that wherever he turns around, there are golden nails begging to be hammered. Software product development doesn’t work that way. You have to match the tool with the task and the project.
• The blob. This one is a class that has a large number of attributes and methods. Splitting the class into smaller ones will help with code clarity.
• Poltergeist. This class appears only to disappear a second later. This is an example of a class that is not needed in the code. Alternatively, it can be swallowed by some other class. If you want to spot a poltergeist… yeah, don’t call Ghost Busters. Use SourceMonitor, it’s safer that way.
• Spaghetti. This type of code is like standing in line for a new iPhone.It’s loooooong. The cure? SourceMonitor and code refactoring.
• Lava Flow. When lava is created by a non-explosive volcanic eruption, it solidifies and turns into a rock. It just sits there. It’s an equivalent of an ancient code that nobody wants to look at and refactor. If something works – don’t touch it. Except when it’s a solidified lava, then you can use the golden hammer. Or a normal hammer. Or even the source control system, coupled with a list of untouched classes. Whatever works for you.
• Kitchen Sink Design. One of the most dangerous anti-patterns out there. Similar to the fantasy kitchen sink (like Star Wars) where everything comes from everywhere and together they form a new organism that doesn’t belong anywhere else than in a pool of cheesiness. Kitchen sink design is about throwing few products into unrelated categories, paraphrasing features in your own words (instead of following standards), alphabetizing within headings, not caring about duplications, grouping features into multiple overlapping headings. And few other, skin-crawling funny little things. Give this code to a junior you don’t like. He won’t be a software product developer for long. Or his hair will turn grey, while he is trying to figure out what the product is about.
• Cargo cult programming. Did you know that there are still local cultures that worship (usually white) man coming by s plane and boats many years ago and bringing civilization? They were discovered usually on remote islands on the Pacific. People actually worship as gods travelers and explorers, coming with things like food. Local tribes built airport lanes to honor ‘gods’. Translating this to software development: it’s using patterns and methods without understanding why.

Project management anti-patterns

• Analysis Paralysis. If you want to analyze the project efficiently, throw few analysts in a room, close blinds and watch the world burn. They will insist on analysis completion before the design actually starts. They will change project leads and undermine each other’s approaches to design. They will compose and decompose ideas indefinitely. Like zombies. Or Michael Jackson.
• Death by Planning. Ever heard of an adventurer that wanted to climb Mount Everest but got stuck on planning? No? Me neither, cause nobody talks about such men. People appreciate doers, not talkers. That’s why management, design and development team should always design, develop, implement, document, test, and maintain architecture. Not talk about it. Stop planning, start coding!
• Yet Another Programmer. Classic management… mismanagement. High turnover leads to continuous software developers rotation. New programmers are introduced to the team. You have to train them, talk about the project and its goals, show client’s needs and challenges. Present the value to the end-user, that’s always the most important thing. That is not a healthy environment, for any project.
• Smoke and mirrors. A favorite technique of magicians and poor project managers. It’s demonstrating the appearance of functions that haven’t been even implemented yet.
• Death march. The most dangerous one. Everyone knows that the project will be a disaster for a number of reasons but the CEO doesn’t care. There is another definition –excessive overtime, even on weekends, for a project that has an unreasonable deadline.

Software design anti-patterns

• Reinvent the Wheel. Also often known as Don’t Do It Yourself. When there’s a tool for it, a line of code, a solution carefully baked by your ancestors when you learn to ride a tricycle, why to waste time on your own, probably not the best code? If you want to learn, just copy. That’s actually not a good idea, because the wheel – although perfect in its shape, can be made with different materials, ergo get better. Learn your own code if you feel like it, don’t follow blindly those who are afraid of implementing changes.
• Swiss Army Knife. A little similar to the previous one and one of my favorite. If you want to open a soft drink, use Swiss Army Knife. If you want to tighten the screw, use Swiss Army Knife. If you want to cut a tree, brew fresh coffee, write new mobile app… You get it. There is no one magic tool for everything. Developers use multiple tools to get results, even Swiss Army Knife has only four functions: it’s a bottle opener, can opener, knife, and a spike.
• Big ball of mud. A system with a structure so unclear that any other, more elegant name would do it unjust.
• Magic pushbutton. No, it’s not creating an ‘it’s raining money!’ moment in your life. It’s about coding implementation logic directly within interface code, without abstraction.
• Gold plating. No, it’s not taken from a ghetto-raper video clip. It’s an approach of working on a task or a project beyond the point where work brings value to this project. It’s burning money, not raining money.

A pretty lengthy list of other anti-patterns is here. Prepare painkillers. And tissues.

What to do when anti-patterns wreck your life?

It all starts with habits. We have recently posted a text about habits in Quality Assurance and we have a few years of experience in software product development, so we can safely say that habits are important. They establish a mindset and framework for future projects and long-term development across multiple projects.

Prototyping is important. Developers are not raised in a vacuum. They are a product of years of experience, knowledge rooted in universities, taken from their colleagues, books, blogs, webinars, and so on. They often rely on past experience to shape the client’s future. Unfortunately, not all their experiences are good enough and filled with positive paradigms. That’s why prototyping is a way to test-drive a mindset. It gives an opportunity for a mindset to thrive when a prototype serves its purpose. By taking it to a given scenario and applying varied approaches, you will have an objective insight into what works and what doesn’t. Following a plan that has assumptions driven from past experiences (often really old and faulty) is never going to beat real-life situations.

Following good practices mixed with common sense and positive experience. This is the ultimate approach. Unfortunately, there is no way to establish one code of conduct when dealing with software product development. A developer is on his own with the judgment and the fallout. Good news – making mistakes leads to improvement. The team can help you but it’s up to each one of us to control what we commit.

If you want to commit your time and talent to the development of software products, check our current job offers. Join CSHARK, one of the most friendly of all software product development companies in Poland.