Invest on your clean coding skills-Part 2
In the first part of this series, I shared some reasons why I believe writing bad code is a horrible idea, here I continue on that before sharing resources and tips to improve coding quality in the third part.
Bad code hinders technology
Another curse with the lousy code is that it can severely limit your opportunities to upgrade to newer technology. For example, imagine that you use a regular ASP.NET WebApp with a regular deployment model on IIS, and the underlying code is highly reliant on file logging directly, without using any proper interface injections for the loggers (i.e. you cannot change the logging mechanism via dependency injection). And now, you would like to containerize your code and use the Docker deployment model instead. But surprise! File logging is not the way forward at all with Docker! Containers are meant to be ephemeral without underlying OS dependency. Now, you will need to refactor your whole logging mechanism and replace it with something that does not use underlying OS resources, e.g., logging to Azure Applications Insight or Amazon Cloud watch.
If your code from the beginning was using dependency injection properly, it would be a matter of concrete class replacement.
Bad code impedes business growth
The current digital world is quite aggressive. Opportunities for business appear and disappear within weeks, mergers & acquisitions, scaling up and down, adapting to governmental regulations, and responding to customers' feedback. All these factors put high pressure on the underlying software systems to become adaptive, lean, and agile like a dough. Well developed software should be scalable, easy to change, and to understand; So that it can serve the businesses in any dimension.
Imagine that your company develops a particular payroll module that is highly hardwired to a specific company with nasty if-else logic that has almost infinite cyclomatic complexity. Then, your company gets a lucrative business opportunity to expand to another region with completely different payroll calculation rules, and the business asks you to adapt to the system. Unfortunately, doing such change to your software is crazy and expensive, and you sadly respond to your project manager/business owner with “NO, it would be almost impossible to this with the current time frame” imagine how much disappointment, shame, and business loss your firm will have.
From my experience, software should be designed to be changed, a rigid software is a kill for the business, there is nothing such as “Done” product. Flexible software systems can be expensive to develop at the beginning, but they reap their value orders of magnitude later.
Bad code limits career opportunities
When you write an ugly, problematic code that you are the only person in the building who can understand it, there is a reasonably high probability that other developers will just escape from that code and resist changing it. It will become the small magic box that no one knows about except you. Whatever change, bug or a new feature needs to implement, you will get contacted and asked to help. Naturally, the people will make sure you are available around, pull you from your other engagements to assist in fixing your legacy crime. Hence, limiting your career and growth opportunities. Therefore, make sure that any code you write lasts as long as possible, and it is easy to change by other people, not just for other people's sake, but also for your sake and your organization's growth's sake.
Bad code can make you incompliant to the law
Software systems are used as a store for data in databases/files/etc. This data will logically contain sensitive business information such as client names, salaries, contracts and whatever you can think about. As a developer of the system, you have the ultimate responsibility to ensure that the data meets all CIA (not the American intelligence agency! But: Confidentiality, Availability, and Compliance) security requirements. You can easily make a bug in your code that corrupts data, exposes sensitive information, or even impacts system availability which can ultimately lead to penalties and brand damage to your organization.
Bad code becomes a habit
One Wisdom I am of fan of is: “Watch your thoughts, they become words; watch your words, they become actions; watch your actions, they become habits; watch your habits, they become character;
watch your character, for it becomes your destiny.”
Someone
And I simply say, watch your code because it becomes your habit. As developers, we spend most of our day writing and analyzing code. If most of our time we are writing bad code, simply it will become a habit, and the more senior we become, the more difficult it will be to change that habit. Fortunately, it is still possible to grow good coding habits even if we are not used to doing so over a long period, as long as we are determined to do so.
Bad code destroys the reputation
How do you feel when you read/review/debug a legacy code that has been written many years ago, and it is incredibly cryptic and full of nested if conditions? Btw: We call such code a Spaghetti code. It merely refers to complex, highly nested code bases.
Whenever I see such code, I just feel something on my stomach: What the hell made that programmer write such low-quality code? It could be an extremely tight deadline, it could be lack of knowledge, it could be laziness, whatever it is, the impact at the end is the same: I really struggle and pain analyzing and troubleshooting that code.
That is all! I hope you are convinced now writing an Excellent code is a must as we will learn soon!