How to Protect Your Company From Messy Code

The Battle for Clean Code

Too often, I hear the woes of a fallen company: the cries of a thousand founders burnt by the all-consuming fire that is messy code. These digital disasters could have been avoided, had founders been taught a few simple things to look for during the process of choosing their software development team.

Software is meant to be soft, which is another way of saying easily changeable. Its malleability lends itself to adaptation, iteration, and change. This soft nature of code is uniquely powerful and essential to innovation and therefore must be preserved at all costs. But messy code is ruthless in its hunt for fresh code to devour. Problems arise when we drop our guard, forgetting Its appetite is never satisfied, allowing our precious code to be destroyed.

What’s that smell?

Messy code is like a messy room; it starts by saying we’ll clean it up tomorrow. However, tomorrow comes and it’s even messier than it was before. We push it off until the weekend, but when the weekend comes and… sniff sniff... we start to smell something funny. The mess seems to be growing organisms of unknown origin which now feed on the decaying matter once known as our room. In code, this mess can be identified by the following characteristics:

Baggage

A single module of code does too many different things. This makes it difficult to reuse in other parts of the code without accepting the baggage, or spending a large amount of time parsing out the desired function from the module.

Rigid

Making a change to one module requires subsequent changes in many other modules due to unknown dependencies buried in the code.

Fragile

Making a change to one module breaks other modules with no conceptual relationship to the code that is being updated.

Opaque

When read, the code is not easily understandable and not clear in its function.

(Unclebob discusses these code smells and more in his PPP Book.)

All these and more contribute to rotting code, rendering it uncontrollable, unpredictable, inestimable and expensive…. Dun dun duuuuunnnnnn.

Why make a mess?

Just like with the messy room, we made the mess because we were in a rush. We didn’t have time to put the dirty laundry in the hamper, or take the trash out. Obviously, making a mess allows us to go faster, right?

Wrong! As the mess piles up, our ability to navigate the space slows down until we struggle to even open the door past the clutter that has collected beyond.

This is what’s called “The productivity trap”. We think we can go fast and be efficient by making a mess, but in truth, we can’t, not in the short-term and certainly not in the long-term.

How Messy Code Can Cost You

Messy code slows down productivity over time, making it more expensive to make changes or additions to the code in the future. You might say “We'll just make them work harder!” However, your development team is already working hard, very hard, they are just not working clean. In this environment the harder they work, the slower they go. You might say “We can add more developers! That will help us go faster!” Wrong again! When adding new team members, there’s always a dip in productivity while we help them catch up. However, once they finally catch up and learn how to make a mess like the rest of the team, it only gets worse as they start to contribute their own mess to the code. As you might imagine, the result is that productivity drops even more.

There will always be “Bugs” in the code. Bugs are unexpected behavior that may break the system. Some bugs are easy to squash, while others hide away in the deepest darkest parts of this messy room we call our code base. If our room is clean, then it’s relatively easy to find that bug crawling around on the open floor. It sticks out like a sore thumb! But pile mounds of clothes, food, and trash on top and that bug will never be found; in fact, it’s probably breeding.

The Questions You Should Ask Your Team

So how can we know our development team isn’t making a mess? After all, us business owners don’t read code, all we can see is the tip of the iceberg as it’s rendered to us by our development team. So before you select your devs, make sure to ask the following questions:

Are you a freelancer, or part of a dev team?

There are two main reasons to hire a development team instead of a freelance developer.

1. Teams are familiar with writing code for others to read. This exchange of code is important because organization is necessary if the team is to communicate well to one another.

2. An individual developer may become ill, or move, or decide they don’t want to work on your project anymore. This means you’ll have to bring in someone new who will probably take one look at your code and want to run for the hills. Teams, or development companies, are more resilient, more permanent, and more dependable.

Do you practice Agile?

Two ships set sail for the mainland. The captain of the first ship holds true to his course no matter what: “A straight line is the fastest route!” The second ship isn’t so convinced. This captain is constantly reading the ocean to determine how she will adjust her course. Yes, you may say that her course is less straight, and perhaps it’s even a longer route than the first ship will take. However, you’ll find that the first captain ends up shipwrecked on an island or devoured by a storm for his lack of adjustment. The second captain will have made it to her destination, as she was able to go around the storms and islands in order to safely arrive at the mainland.

The moral of this story is to “commit to the mission, not the course.” We must be constantly evaluating our course, making many decisions along the way to be sure it is still the best route. Agile gives us constant feedback, allowing us to make course adjustments along the way to completing our project. This iterative process leads to innovation and a greater success rate.

Do you practice TDD (Test Driven Development)?

A test is like proof. If a code doesn’t have tests, then there is no proof it works. TDD takes this to the next level, requiring those tests before the code is even written. If your developers are not practicing TDD, then they are not proving the code functions in the way it was designed.

Do you have experience building large apps from the ground up?

DNS, Server admin, SSL, HTTP, Cloud Infrastructure, Database, Deployment, Security, Scaling, Lions, Tiger and Bears, OH MY!

These are just a few of the scary beasts that need to be tamed in order to build a new app. Simply knowing how to code doesn’t cut it. Inexperienced developers haven’t dealt with these animals yet, and even years of experience doesn’t promise knowhow because their experience could have been in a specialized role (like dog grooming), not bear wrestling.

You’re looking for true explorers who’ve braved the wild, and bent it to their will. Make sure to ask your devs if they’ve handled these beasts before… especially the bears.

Final Thoughts

From Baggage to Beasts, these are the things to look for when choosing the right dev team in order to keep your code clean and smelling fresh. You can learn more in our video series on Clean Code. If you have a particularly smelly situation, or would like to get started on the right foot; then reach out to our Clean Coders Studio and we’ll help you tackle the most daring software feats.

Stay clean my friends,