Code quality isn't software quality by Mark Seemann
A trivial observation made explicit.
You'd think that it's evident that code quality and software quality are two different things. Yet, I often see or hear arguments about one or the other that indicates to me that some people don't make that distinction. I wonder why; I do.
Software quality #
There's a school of thought leaders who advocate that, ultimately, we write code to solve problems, or to improve life, for people. I have nothing against that line of reasoning; it's just not one that I pursue much. Why should I use my energy on this message when someone like Dan North does it so much better than I could?
Dan North is far from the only person making the point that our employers, or clients, or end-users don't care about the code; he is, in my opinion, one of the best communicators in that field. It makes sense that, with that perspective on software development, you'd invent something like behaviour-driven development.
The evaluation criterion used in this discourse is one of utility. Does the software serve a purpose? Does it do it well?
In that light, quality software is software that serves its purpose beyond expectation. It rarely, if ever, crashes. It's easy to use. It's sufficiently responsive. It's pretty. It works both on-line and off-line. Attributes like that are externally observable qualities.
You can write quality software in many different languages, using various styles. When you evaluate the externally observable qualities of software, the code is invisible. It's not part of the evaluation.
It seems to me that some people try to make an erroneous conclusion from this premise. They'd say that since no employer, client, or end user evaluates the software based on the code that produced it, then no one cares about the code.
Code quality #
It's easy to refute that argument. All you have to do is to come up with a counter-example. You just have to find one person who cares about the code. That's easy.
You care about the code.
Perhaps you react negatively to that assertion. Perhaps you say: "No! I'm not one of those effete aesthetes who only program in Plankalkül." Fine. Maybe you're not the type who likes to polish the code; maybe you're the practical, down-to-earth type who just likes to get stuff done, so that your employer/client/end-user is happy.
Even so, I think that you still care about the code. Have you ever looked with bewilderment at a piece of code and thought: "Who the hell wrote this piece of shit!?" How many WTFs/m is your code?
I think every programmer cares about their code bases; if not in an active manner, then at least in a passive way. Bad code can seriously impede progress. I've seen more than one organisation effectively go out of business because of bad legacy code.
Code quality is when you care about the readability and malleability of the code. It's when you care about the code's ability to sustain the business, not only today, but also in the future.
Sustainable code #
I often get the impression that some people look at code quality and software quality as a (false) dichotomy.
Such arguments often seem to imply that you can't have one without sacrificing the other. You must choose.
The reality is, of course, that you can do both.
At the intersection between software and code quality the code sustains the business both now, and in the future.
Yes, you should write code such that it produces software that provides value here and now, but you should also do your best to enable it to provide value in the future. This is sustainable code. It's code that can sustain the organisation during its lifetime.
No gold-plating #
To be clear: this is not a call for gold plating or speculative generality. You probably can't predict the future needs of the stake-holders.
Quality code doesn't have to be able to perfectly address all future requirements. In order to be sustainable, though, it should be easy to modify in the future, or perhaps just easy to throw away and rewrite. I think a good start is to write humane code; code that fits in your brain.
At least, do your best to avoid writing legacy code.
Summary #
Software quality and code quality can co-exist. You can write quality code that compiles to quality software, but one doesn't imply the other. These are two independent quality dimensions.
