5 Practices to Eliminate Bad Code

Have you ever been there? A deployment goes live and almost immediately, someone points out there is bad code somewhere causing an issue. Bad code is not fun. 

There are many ways, tools, and practices that we can take to ensure that bad code never sees the light of day in production. I sat down with several industry experts to take a look at how we can put an end to bad code once and for all.

Eliminating bad code? We got this!

You may also like: 3 Reasons Why People Write Insanely Bad Code

Step One

“Computers do not assign meaning to structures or apply semantics to statements. Instead, they blindly store bits in registers, flip the input of gates, and electrically transfer data across buses. Too often, we make the mistake of writing code that a computer can understand, rather than a human.

We shorten variable names, create cryptic structures, and even provide comments to mask the obscure nature of our code. If we want to write better code, we need to focus on writing code for people. Whether it is a coworker in our office, an open-source contributor half a world away, or ourselves, people are the primary readers of code.

One of the best ways to write good code is to write code for a human audience. We need to change our approach and write code as if it were a book: A book that reads from top to bottom and tells the story of the problem being solved. A book that uses variable names, method names, class names, conditional statements, and the other programming pieces as the sentences, paragraphs, and chapters that explain to a person how our application solves the problem at hand.

This is more of an art than a science, and it takes great discipline and practice, but it pays immense dividends. Always write code so that a stranger can read it and easily deduce exactly what it is trying to accomplish.”

— Justin Albano (@justinmalbano), Software Engineer at Catalogic Software

Step Two

"In order to reduce the amount of bad code we see; I believe in being inspired by alternative sources. For instance, I oftentimes myself perceive coding as more of an art form than engineering. If we then allow for this art form to become inspired by other types of art forms, such as music, painting, sculpturing, etc. — It will draw people into wanting to understand it.

To facilitate this, ask yourself the questions of "What rhythm does my code have", and "What's the color profile of this particular piece of code", etc. This allows you to see the code from a more holistic perspective, making it appear to have a uniform whole, instead of multiple brilliant details, clashed together, resulting in a patchwork of different styles.

Beautiful code should "sing" to the recipient, and be amazingly simple to understand, and the product as a whole should be based upon a single idea, and this idea should be visible throughout the entire product. In such an environment, creating bad code becomes almost impossible. Basically, standardize the way you produce code.

To standardize your code, and make it sing, make sure you use tools wherever tools can be used. Copying things off from StackOverflow, and applying a couple of bugs to it in the process, is something everybody can do. Using the right tools, is something for weird reasons fewer seem to understand the importance of. Neuro typicals use computers because they help with the task at hand. Developers should think the same way"

— Thomas Hansen (@MisterGaiasoul), Chief Crudifier at Server Gardens

Step Three

“Work with and learn with others. Most developers are passionate about their craft. Craftsman continually refines their skill. They try new things. Something that doesn't turn out quite right is looked upon as a lesson learned. Developers that get together with other developers will always learn from one another. Meetups, Birds of a Feather session, etc. provide wonderful opportunities to share and learn.

It doesn't matter how much experience you have. It's never a one-way street. Never stop learning about other languages, stacks, and tools. They were all envisioned to address a challenge. In fact, regularly develop something in new technology.

Let the tools do the mundane work. Spend time configuring IDEs, editors, command-line tools, shell environments. The more these are refined, the better one can focus on the real task at hand - delivering functionality. It's not just about the mundane work either.

Good tools spot problems and offer suggestions. Trust them. There are decades of knowledge behind these insights. Obsess about eliminating all of the observations being made by the tools. The code will be better, people that follow will appreciate the effort, and the author of the code will have improved their skill.”

— Ray Elenteny, Principal Owner Solutech Consulting

Step Four

"In our organization all the coders do is code, but we have a fraction of the number of developers that we used to have. We try not to bury them in bug fixes because we saw so many new things written. By giving them access to the Dynatrace tool it helped them remediate problems quicker. With the DevOps now they're interfacing more with operations.

The advance with the Dynatrace tool in our company started first in software development. I got them into it because of the coding capacity of the product to be able to identify bottlenecks in the code. If I have an error, and it's a SQL error it'll drill down into the SQL statement that's causing the problem.

This saves a lot of time for developers. From there in operations, we deployed session replay so that when a customer has an issue, they can bring up the customer in session replay to and watch what was happening to be able to identify the single area that may give up and walk them through it and get it fixed."

— Mark Kaplan (@MarkDavidKaplan), Senior Director of IT at BARBRI

Step Five

“We talk about quality gates at Dynatrace, and it's basically after you execute your tests you look at these SLIs and SLOs. You hopefully have some automated process that builds, deploys, and runs tests.

Normally, right, you either had no time and just promoted it like throwing it over the wall, and now with Dynatrace, every time you deploy and test, we are monitoring everything. We monitor your response time, your resource consumption, and we monitor architectural KPIs as well.

Hey, your code used only to make one database call for this particular feature. Now you're making 50 calls, and you're making an additional call to external service. Are you aware of that? I want to make you aware of it because maybe this is actually an unintentional bad code change that should not go into production.

The good news is we're doing this fully automatically. That means if you integrate Dynatrace in your pipeline, we can let Dynatrace look at these key metrics. So, the classical response time failure rate memory consumption, but also architectural metrics. How often do we communicate with which other services?

You look at the build by build and then automatically say, "Hey, something is wrong, you just increased the number of database calls by 50%, and you included two new dependencies. Do you really want to push this into production? Yes or no?" That stops bad code, and also configuration and architectural changes before they hit production.

The best thing is if you not only do this at the end of a release if you integrate this in your build cycle of every commit. With every commit you build you deploy, you run some meaningful tests, and you'll look at the Dynatrace metrics. You're doing SLI and SLO validation, but not only on the standard performance metrics also these architectural metrics and scalability metrics.”

— Andy (@grabnerandi), DevOps activist at Dynatrace

Summary

1. Automate everything you can automate.
2. Treat code like art.
3. Collaborate and learn from others.
4. Write beautiful code human beings can understand.
5. Use the right tools to become better. Cloud development tools like those from Dynatrace can provide entire organizations with enhanced automation that will enable developers to more rapidly deploy and free themselves from the curse of bad code practices.

Further Reading

Reusable Code: The Good, the Bad, and the Ugly