Every once in a while, any software developer wants to write a piece of art by following best practices such as refactoring or improving your code, adding unit, integration or even end-to-end tests, making your code as readable as possible, or delivering solutions that scale in no time. It is like going to Hawaii for your honeymoon as software developers; you are dreaming about making that happen.
However, you came here to find a solution to a problem you constantly battle when you start working under tight deadlines while maintaining quality code. You came here because you are a proud developer who constantly strives to produce quality code, who constantly wants to convert a one-scenario solution into a more generic solution that covers more scenarios but requires extra development. Or simply, you came here because you are curious about this topic.
I am one of those developers who flinches after delivering code that makes one turn into tears whenever they go back and start reading and understanding the logic behind it. However, I have learned over the years certain things I have to swallow and accept the way things are.
The reality is that clients pay thousands, millions, their life-time savings to have a functional product. What does functional mean? It doesn’t mean how many lines of code you put in a method/function, nor whether your code has been refactored or not, nor whether you created an API endpoint with an absurd long name or with a more concise name, nor whether or not writing code that scales or that has to be changed every time new specs are changed.
A functional product means the software, web application, mobile application, game, or whatever else you can develop works. It means if there is a contract that has been signed between the two parties, the client and the service provider, with deadlines clearly specified, it needs to be delivered whenever it is supposed to be delivered.
Sometimes, you can gain time by talking to the client beforehand about the current stages of the development process, and the client allows you to deliver outside the initial timeframes. However, that is not always the case. For example, the client had already publicly announced about the exciting app their users will get to enjoy, but the developers are still working on it.
Having said that, a functional product means you must finish and deliver on time. It is the moment when the “whatever it takes” rationale starts becoming part of your thoughts. It means the chances of writing messy code skyrockets just with the thought of knowing you have 1 month, 1 week, 1 day, 1 hour, or even 1 minute to get the project up and running.That is the point when experience and rationale come into place. That is the point when you should calm down and start thinking about what you are putting in the code. That is the moment you should keep thinking about writing clean code. That is the point you must write easy-to-read code. Just because your code does not have unit tests or it lacks refactoring, it does not mean it cannot remain easy to read.
Code readability is part of the process of writing clean code. It is one of the most basic concepts, but hardest to follow within the world of software development…even when there are tight deadlines…even when everything is a rush…even when we need to get it out there as soon as possible…even when a function has 500 lines of code…
…Even if there are multiple valid reasons why your code is not fully clean, code readability must be there.
But why is this so important? It is important because it will simplify the process of integrating new functionality. It will ease the process of getting up-to-speed new developers who join the development process to add more features and finish on time. It will be easy in the long run to refactor. It will be easy during post-production deployment whenever you start adding unit tests. It will be easier to write documentation based on that code.
It will be easier.
You see, there are certain things that are not perfect and that is fine. If you don’t believe me, I recommend you go back and check the code you wrote 3 months, 6 months, 1 year, 5 years, 10 years from now. You are going to say: “What in the world was I thinking when I added that code?”, or “I think I was high when I wrote that piece of code”.
It happens…, even to the best of us (cough). Sorry, I meant to the best developers in general.
Back to the point…if you were able to read that old code without digging much for additional information, that means you wrote clean code. It may be in its most basic level, but it’s still clean.
It is like having minimum standards.
All in all, continue writing clean code even when you think it needs to be improved. Even when you must deliver under tight deadlines. Sooner or later you will notice you naturally write clean code because you set high minimum standards for yourself.