If you’re reading my blog posts as they come out then you already know about CLEAN, which is my acronym for five code qualities that improve the testability and maintainability of software.
If you’re reading these posts as archives in reverse chronological order, then the acronym is: NAELC. It’s unpronounceable, but it still contains goodness. As you read through my previous posts you’ll find out about these code qualities: nonredundant, assertive, encapsulated, loosely coupled, and cohesive. Of course, there are many more than five but let’s just focus on these five for now.
Regardless of whether you read these blog posts chronologically or in reverse order, these five code qualities are important indicators of the overall quality of code. They’re little things that make a big difference, like the bolts on a bridge.
Bridges are huge, expensive projects and they are held together in part by inexpensive bolts. If we try to build a bridge without paying attention to tightening the bolts then the bridge will collapse. We all know that a chain is only as strong as its weakest link. The same is true with virtual things but strength and resilience and longevity depend on things that are subtle, like these five simple code qualities. I know people who disagree with me and say that users don’t directly see code so what does it matter if it’s “clean”? But users do see these code qualities indirectly and they experience how well a program is able to respond to change and meet a user’s needs. Drivers may not see the bolts on a bridge but they expect them to be there or they’d never drive across it.
When these code qualities are present, software is vastly more understandable, which makes it more straightforward to work with. Software is, after all, an asset and in order for our asset to continue to provide value it has to be at least somewhat flexible. But software that is not CLEAN can be inflexible and difficult to change, which is one of the main reasons it costs so much to change existing software.
To me it’s ironic that we complain about the little extra effort it takes to write CLEAN code, but we seem all too willing to pay exorbitant prices to extend it later on because guess what guys—when we don’t pay attention to code quality, we end up with legacy code.
Legacy code isn’t just the bane of our industry, it’s the bane of all industries because all business depends on software and the way we build software is fundamentally broken. It’s broken because we don’t pay enough attention to implementing CLEAN code. We don’t want to take time to think about the object model or to put some little bit of behavior that we discover is needed into its own class. Why? Is it really so hard to type in those eight characters “class {}”
If we want to build an industry then we have to promote practices that work for everyone. We have to build software that’s more reliable, that’s more efficient, and most of all that’s more extensible. Because it turns out that the vast majority of expense in software is making minor enhancements to already existing systems.
But it doesn’t have to be that way. There are best practices and techniques that we can use to help us build a shared understanding of what we’re doing and how we’re doing it, which, by the way, is not nearly as obvious as constructing a building. Software is invisible in many ways, and being clear on exactly what we’re doing and why we’re doing it has profound implications on how well we do it. That’s why I’ve written this series, to discuss the concept behind these key code qualities.
One thing I’ve noticed about virtually all of the very best practices I’ve seen in software development in my career, as well as everything I’ve learned about good principles and patterns, is that all of them imply CLEAN code. All of the example implementations of design patterns are CLEAN. The SOLID principles are CLEAN. When we do TDD, the code that we produce is CLEAN. And so by studying CLEAN code, we can infer many of the principles, patterns, and best practices used by expert software developers.
In case you want to read my series of posts in CLEAN Code Qualities in chronological order, here’s the first one.
Previous Post: « Nonredundancy and Testability
Next Post: Let Code Quality Guide You »