Code quality is not just a whim; it's an obligation of every Software Engineer

I've recently read this great article that talks about "good enough code is not enough"

It's been a long time since I want to write about this topic but never had the time for it, so here we go.

Let me start with a few takeaway quotes that I selected from the article mentioned:

"good enough” mantra is that it promotes a culture of mediocracy"

"Such code can potentially hurt everyone involved: the customers, the programmers, and the rest of the company.?"

"Striving for excellence is not just a matter of professional pride; it is necessary to prevent the endless cycle of suffering."

“The sins of the past will come to haunt you! Tech debt must be repaid!”?

With these quotes in mind, let me add a few thoughts on some reasons why people justify not investing the time for writing good code:

"It is too hard - I will write more lines - I will create more files etc"

Writing good code is not significantly harder than writing bad code; it does take longer initially, which is a fact. However, this initial investment saves vastly more time in the long run, as we spend much more time reading code than writing it. After all, good code is not only more readable but also more testable. Testable code significantly reduces the need for manual testing (perhaps to a minimum), likely results in fewer bugs, and decreases the likelihood of having to fix urgent issues in the middle of the night.

Most mid-level Software Engineers don't know how good code looks like

The problem with distinguishing good from bad code is that most developers with less than 5-7 years of experience have likely never been exposed to high-quality code. Consequently, they cannot recognize good patterns, which also means they struggle to replicate such quality in their work. Developers at this level often underestimate the importance of writing testable code that isn't tightly coupled with the latest libraries and frameworks. They may not understand the difference between domain and application logic, or recognize the distinct responsibilities of frameworks and libraries versus the application they're developing. It's surprising how many mid-level developers are unaware of the difference between dependency injection and dependency inversion, let alone why these concepts are important. Additionally, many of us work on legacy applications burdened with technical debt, further complicating the challenge of improving code quality by replacing poor code with better alternatives.

I am not suggesting that merely accumulating years in the software development field guarantees the ability to write good code. Indeed, I have encountered quite a lot of indecipherable and poorly written code by programmers with 15-25+ years of experience, turning their work into an intractable mess that no one can understand or extend.

Some Software Engineers Don't Even Care

In the past, I've worked with software engineers who openly admitted they didn't care about writing good code. To me, this is a dreadful attitude. Why would anyone choose to work in a field yet disregard the craftsmanship inherent to their profession? We expect excellence from a plumber fixing a sink in our house, and we demand care and skill from a carpenter crafting a bench for our porch. Yet, some engineers write substandard code, increasing the financial burden it places on the company paying their salaries, not to mention the sleepless nights it causes for other engineers tasked with untangling their mess later on.

I've witnessed these very same software engineers justify the poor quality of an application they developed by blaming frequently changing requirements. Their proposed solution was to rewrite the application from scratch. However, they ended up creating the same mess, as the new code exhibited the same problems as before. This issue arises not only because they don't care, but also because they lack an understanding of what good code quality entails. As I've mentioned, improving code quality requires deliberate learning and the application of patterns. How can this improvement be possible with someone who openly admits they don't care?

What are the possible solutions for that?

I'm not claiming that I write perfect code either. I've authored my fair share of problematic code that has, unfortunately, become someone else's burden. However, over the years, exposure to various concepts, patterns, and techniques has helped my understanding. If you're deliberate about learning what constitutes good code, you begin to recognize and integrate these elements. For me, one measure of whether my code has improved is based on several criteria:

• People can understand my code without too much trouble.
• My code is UNIT testable. While integration and E2E tests are important, they don't speak to your code's quality the way UNIT tests do.
• My code is expandable. Can I add new behavior to the existing code without extensive rewrites?
• Can I replace an old NuGet package with a newer one that offers the same functionality but more efficiently? Or, can I switch out a no-longer-maintained package with another that is actively updated by its developer on GitHub?

Experienced Software Engineers don't neglect PR Reviews

I know that PR (Pull Request) reviews are not agile, they are the opposite of agility, however until we get to educate companies and it's managers that pair programming is a good thing, let's use what we have.

PR reviews offer an excellent opportunity not only to safeguard the application from accruing technical debt but also to educate software engineers on crafting high-quality code. Establishing a robust PR review framework within your team creates a win-win scenario: it facilitates knowledge sharing and presents a valuable learning opportunity for less experienced members. However, we know that some experienced software engineers sometimes overlook the importance of diligent PR reviews, which is a significant oversight. They act as the final guardians of the codebase, shielding the team and the company from future software maintainability costs.

Regrettably, I've also encountered the disappointing situation of spending considerable time reviewing a PR filled with bad code, only to have the author seek approval from someone known for lenient PR assessments, ignoring all my feedback. It's undeniably frustrating, but some factors are beyond our control. We do our best with what we can influence.

Anyway, those are my thoughts... I had to put it out of my chest.

I might or might not come back to this article in the future to expand more with some concrete examples taken from code bases out there. (If time permits)