“CLEAN CODE”, PLATONIC LOVE OF PROGRAMMERS

There I was, working on a little project for a client in his office when my colleague Peter called me about some tests that needed to be run on an old application I’ve helped develop a year ago. Nothing too shabby, just some connectivity issues with another system that might lead to some change requests, a piece of cake. However, I have forgotten almost everything about that application and, to my surprise, the code was quite messy, without much clues about what did what and why. On top of that, the other lead programmer of that project had left the company so there wasn’t a lot of room for questions. So after doing the required tests (which did take me a lot more that what they should have), many questions puzzled me. The first of all being WHY?

After all, I took part in that project and some of that messy code came from my own hands. From the first moment, I was hired by Lithium I took a lot of care of my code and put special emphasis on detecting dirty code to refactor it and make it better. All driven by the slogan we are so keen on: “Let’s do things right the first time”. This of course doesn’t mean that you don’t review your code and iterate over it to improve it, but rather that you make sure it’s understandable and correct before moving on to other chunk of code or even project. All that being said, that messy code stood there as proof that, sometimes, it is easier said than done. So what led to that mess?

You see, us programmers have a sharp eye to spot messy code (and a tendency to criticize it…), yet we sometimes struggle to write “clean code” ourselves. The main reason being that writing ‘clean code’ is hard. User requirements are sometimes poorly specified and tsunamis of new ones arrive at the worst moments. Still deadlines have to be met, sometimes resulting in unpolished patches. Writing good code is like writing a novel or a blog, once you know it does what it’s meant to do, you need to read it several times and be sure it’s clear to everybody. Several iterations might be needed to achieve methods and routines that can be understood by any programmer that joins the project or even by yourself when you leave it for a long time and have to come back someday. This requires as much dedication, knowledge and practice as time, the latter being the most scarce. Clients usually prefer new features rather than wasting time and money on code refactoring that seems to be only visible for developers, so when you release a rushed feature you are pretty much screwed. I have seen many people say stuff like “It doesn’t matter, we will tweak it when we have time” and we all know that will never happen. When time goes by and you start forgetting how things worked on that stinky code, the technical debt is usually already too high to be paid. Having this into account, how can we developers convince clients or even our own bosses to invest in code quality? What are the steps to write good quality code?

Up until now, I have talked about this so called ‘clean code’ as that platonic love programmers aspire to conquer, without giving a proper definition of it. To be honest there are several books that can help you get a better understanding about ‘clean code’ and how to craft it, most noticeable being “Clean code: A Handbook of Agile Software Craftsmanship’” by Robert C. Martin (which I totally recommend by the way). To keep it short, “clean code” could be defined as code that is robust, follows design patterns and, most importantly, is understandable. As Bjarne Stroustrup, inventor of C++, stated: “… the logic should be straightforward to make it hard for bugs to hide…”. This goes from choosing variable names to the whole architecture of the system.

As stated before, achieving this type of code is hard and it does cost money. However, bad quality code has proven to take most software companies to their knees. Clumsy code leads to more bugs that are further aggravated by how difficult and time consuming it is to fix them, again, because of bad quality code. Programmers start to get demotivated, which in turn makes them more prone to generate more spaghetti code or even leave the company. So the next time you have to convince a boss or client to give you more time to polish your code, do take some of this factors as arguments. Even better, make writing good quality code your second nature and avoid arriving to a situation where a big and money consuming refactor is needed. If not, someone (be it you, a colleague or your whole company) will pay the price. Trust me, I had to learn this the hard way. “Let’s do things right the first time”.

PD: Special thanks to Ariel Erlijman, my former Agile Methodologies professor, for further inspiring me to take good care of code quality.