I "Love" Anti-patterns

Everyone talks about design patterns, but getting to know the other side of the force can be as enlightening as visiting the old good friends. I don't like to produce them, of course, but rather learning about them. As developers we're always trying to improve ourselves, but to be able to improve we need to make mistakes and some of these are mistakes we make during our careers. Getting to know the most common ones can help us steer clear of them. Here I present a top 5 with my favorite ones :)

5 - Big ball of mud

This is a nice way of referring to a piece of code that doesn't have a clear architecture. Many of us are guilty of producing balls of mud in the beginning of our history with a technology. I remember when I was beginning with Android writing a lot of code inside the Activity and hoping for the best. Some symptoms that you have a BBM:

• A lot of repeated code
• Data is completely decentralized, appearing in many locations and many times repeatedly
• The code looks like it's been patched many times by many different people.

The original term was coined by Brian Foote and Joseph Yoder and it says:

A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle.

This is easily remedied with the use of an architecture, or a minimum level of organization in our code.

4 - Design By Committee

A.K.A : Gold Plating, Make Everybody Happy
Gold Plating is the foe of perfectionists. It's simply wanting to add more and more features, even tough the product is ready. It's also all about being too elaborate or complex without needing to be so. Some symptoms that this is happening:

• Meetings are taking excessively long time and don't feel like grasping the important aspects of the project:
• Design development costs more and takes more time than initially planned.
• Overly designed feature beyond the scope of the client's requirements.

To keep things on track: the duration of the meetings and the sticking to the requirements are essential.

3 - Cargo cult programming

Have you ever joined a cult? Was it fun? Or did you spent most of the time not knowing what actually was going on there? (insert awkward face)

Well, that's basically what cargo cult programming is. You've just heard of a new tech, process or tool and you simply want to join in the hype even though you know nothing about it. Usually, this happens when we're young and fresh in our trade, but sometimes more experienced developers are guilty of joining in. Some symptoms this is happening around you:

• Use of technologies just because it's "trendy" without evaluating the costs of implementing it
• Copy-and-paste programing

2 - Lava flow

You know that room in your house where the messy stuff lives. Or even that pile of clothes that gets shifted around in your room and that would be much better off organized inside your closet? Those are your own personal lava flows :)

Lava flow is that piece of code that gets shifted around in our projects just because we don't want to think about all the work it would take to get rid of it. You know it's useless, ugly and potentially buggy. But the stress of working on it puts you off from the necessity of striping your project off it. Sometimes it's code you didn't even write and you're like 99% sure it's not used anywhere. But that 1% keeps you from cleaning it up.

Some symptoms that you have this in your project are:

• There's a part of the code where nobody likes to go.
• Some bits of the code look important and "might" be used somewhere else.
• You refer to some bits of your code as "that part that (insert the name of a previous colleague) did, it probably serves a purpose, probably...(awkward pause)"

1 - Copy and paste programming

We've all done this once(and still do) and I'm not saying it's wrong copy and pasting from other sources. Code reuse is a primary topic and foundation in our trade. We can't reinvent the wheel every time we need to add a new feature to our app. The world is huge and many things have been tried, tested and done, so why not reuse what's out there?

The problem rises when we overdo it, or do it without thinking. Copy and paste solutions without analyzing the impact of them in our code or in the overall architecture of the project is bound to cause many headaches down the line. Some of the symptoms this is happening in your project are:

• You see the same bug repeating itself, even tough you've fixed it somewhere else.
• Your code starts looking like a piece of (literally) patchwork.
• Some parts of your code become obscure as you don't actually know how they work.

A culture of quick-fixes rather than code quality can stimulate such Anti-Pattern. A simple fix for this is to create a culture of code reuse that stimulates analysis over speed.

Most of the patterns here are discussed in depth here
That's it, I hope you guys enjoyed the reading :)