Clean Code as a Business Asset

 |  Writings

The "clean code" term's meaning has worn out completely due to careless usage. It has come to mean everything but its actual value. This is especially true for business people who don't even hope to understand what clean code is.

Let us recap. Clean code is not some specific form of code. Clean code provides a clear set of actual real-life deliverables: reliable, error-free digital products that meet customer needs; engineering assets that evolve smoothly with the business; and a professional engineering culture that provides quality and productivity over time.

Clean - professional - code is the shortest, defect-free, no-debug, created in the shortest possible time, doing exactly what the subject domain expects, a pleasure to read, and a pleasure to modify.

The Investment Returning Multiples of Its Cost

It's a business investment that lasts for years — potentially decades — delivering at least 3–5x return over the lifetime costs of careless code. It pays back multiple times in many ways.

In avoided application error losses: the business's direct ones, and those its customers would have otherwise suffered 1.

In new engineers' onboarding time (multiple engineers × multiple times), and value 2.

In the ongoing positive team selection: clean code attracts professional people. Developers and engineers first, others consequently. That, in turn, creates a uniquely productive culture for the business: positive, error-free, risk-controlled, creativity-inducing, healthily urgent. And more 3.

The professionally written code is, actually, the only code quality that should be chosen for commercial production applications.

Writing products in professional code is times faster than in careless code.

This is because of careless code reworks and throwaways (absent requirements and design) and bugs (absent A/TDD). It is because changing functionality modeled in an engineering model is 10-100+ times faster and error-free than changing the functionality modeled 4 in code.

But. Learning to write professional code takes about 20 times more effort than writing careless code.

To Those Striving to Professionally Write Code

A true aspiring engineer can feel they write bad code.

Each new line and module gets harder and harder. Debugging becomes messy and often gets stuck. It feels bad when they require touching the code once made working. A change always brings the fear that the code would not work. Debugging gets even messier after changes. And even messier over time until the code is no longer changeable. Who told you a software is soft?

I suspect every software developer (except those rare ones trained by actual professionals from the very start) felt that way at the beginning. The majority never left that beginning phase despite years of practice.

Writing clean code feels completely opposite of the above feelings. Feeling the constant joy and satisfaction the more code you write, release, refactor, change irrespectively of its complexity - that is the sign of professional code.

Now, practice does not make perfect. Bad practice makes bad. Mediocre practice makes mediocre. Continue accordingly.

To write clean code you need to adopt writing clean code all the time. Consciously. Make it a rule. Then consciously see where and how much to bend the cleanliness toward bad, mediocre, simple and stupid, or just stupid. Consciously.

Clean code has no code smells. It radiates competence. To code clean, apply the "no code smells" requirement. Not a single one. Take the books 5 and work through each smell to know and always avoid them 6.

And before blaming others for non-clean coding, first yourself show others your code is 99% actually clean, top-quality and 1% the cleanliness is bent for a reason.

"Show me your code" - is as needed statement today as it ever has been.

Footnotes

  1. Times? Orders of magnitude? Risking the law suits to the business? The business bankruptcy? ↩

  2. Professional code is the up-to-date, broadest, deep concentrated knowledge about the business, quickly, effortlessly, pleasantly absorbed by professional software engineers. ↩

  3. Save on people turnover costs? ↩

  4. as they both are models of the real world business process; ↩

  5. Start with the following two: Fowler M., Refactoring, (1999 or 2018), Wake W., Refactoring Workbook (2003). Learn and then master to recognize and avoid each one code smell in your code. As your experience grows study these books: Boswell D., The Art of Readable Code (2013), Martin R., Clean Code (2008). ↩

  6. In addition automate code smells detection with tools, e.g. SonarQube Lint is convenient to use in daily work. ↩