Quality is a word we throw around a lot, but without much consensus on what it really means. And it can mean different things in different contexts. Quality in software is very different—the word has a fundamentally different meaning—from quality in goods or services. This is because software is fundamentally different than goods or services. Software is a little bit of both, and something else entirely.
When most people talk about quality, they’re thinking about the quality of the experience. For example, quality in software means it has a good and consistent user experience, the program runs, is easy to use, is free from defects, and so on. These are external qualities of software. But there is another set of qualities I would rather focus on: the internal qualities of software, the qualities related to the code itself. Internal qualities are causal and measurable, are actually quantitative and actionable so as you improve these qualities, the overall quality of your code also improves. And being able to measure specific qualities in software gives us the ability to evaluate aspects of it and identify what code supports maintainability and what doesn’t.
When I was writing Beyond Legacy Code: Nine Practices to Extend the Life and Value of Your Software, I wanted to write about the most valuable Agile practices I’ve used, but these were technical practices which are rarely written about for a non-technical audience. It’s easy to talk about what good practices are but a little more difficult to talk about why they’re valuable so we can really understand them and use them to their fullest.
But I had a challenge.
I can introduce people to some basic concepts, but how do I communicate an understanding of what good code actually is and why it’s important to write good code in terms of the ability to maintain and change the code in the future.
I’ve studied and taught advanced software design for many years and to do so I draw on a range of a well-known principles and practices. I’m a vocal proponent to design patterns as well. But sharing that information would take volumes. Somehow I had to convey the core principles for developing maintainable software in less than twenty pages, which all the room I had for it in my book. So instead of focusing on theory and principles, I decided to focus on five key code qualities that tend to be present whenever we use good principles, practices, and patterns.
These five qualities of code are independent of the language being used. Some languages, particularly object-oriented languages, make it easier to apply these code qualities but they exist or don’t exist in all code regardless of the language being used.
I think of these five code qualities as fundamental. You may be familiar with the terms from college textbooks but I would like to go deeper than those texts would normally go, so over the next several blog posts I’ll be discussing little code qualities that make a big difference in terms of the maintainability and extensibility of software.
These five code qualities are the keys to dropping the cost of ownership for the software you build.
By the way, I‘m not talking about the so called “quality factors” or “–ables” as I call them. For example, reliable. If I tell you your code should be reliable I haven’t helped you very much because I haven’t told you how to make it reliable.
So then what are these five magical qualities in code? Well, I’ll answer that question in my next blog post so stay tuned and I’ll see you next week. Until then, share what works for you!
{2 Comments }
Previous Post: « Beyond Waterfall Software Development
Next Post: Keep it CLEAN »
David,
After decades in pursuit of software quality and reading your excellent book, I look forward to reading this series of posts. (Yes, I owe you an Amazon book review.)
I trust that they will address quality factors at some point. As you may recall, my operational definition of quality is that it is a function of the salient QFs, in context.
Thanks for writing on these topics.
Cheers, Ian
Hi Ian,
I’m looking forward to you checking out this series. I may have a bit of a different perspective on code quality but I think you’ll appreciate it as well. Enjoy!
David.