I'm rather obsessive about code quality - ask anyone who knows me. This is the culmination of my experience working with many software engineers with a wide range of development experience. Ranging from mentoring individuals fresh out of college, to prior-military, to what someone once referred to as 'elite' devs, code quality has become very important to me. As I've progressed through my many years of software engineering experience, it's become apparent to me that software engineering code quality has become a bit passe in many development environments. Reasons that I have heard about why certain individuals don't care about code quality is that it has minimal impact on performance, it is difficult to prove that there's any significant impact to the bottom line, and slightly more abstractly, that a bad pattern followed by all developers in an organization is better than a good pattern, partially implemented. I'm starting to hate that last argument, and I'll explain why. What I will not do here, is describe what I mean by quality, since I already did here.
Performance is king. That is to say, as long as the code performs (to end user expectations), then it doesn't matter how good or bad the underlying code is. I would agree with the inverse of this statement, suggesting that non-performant code is bad, and no matter how 'good' the underlying code is. The difference is subtle. The first statement suggests that there's no reason to consider code quality at all, and the second suggests that it is okay to focus on code quality, as long as performance is not degraded below what the end user expects. I would suggest that code quality can negatively impact performance. I have seen this, in fact [link to Emergent Patterns coming soon].
I confess that it is notoriously difficult to prove that code quality has any impact on the bottom line. But, as we software engineers know, difficult is not the same thing as impossible [link to paper on this]. Krugle suggests, by inference, that the code maintenance cost has gotten worse, and not better, with frequent releases. They state that approximately 50% of the entire software engineering effort in a company with more than 100 developers and over 500k lines of code (although the studies are somewhat dated). I wouldn't have guessed the number was that high, but Omnext thinks the number is actually upwards of 90%. What does that mean to you? Let's say you have 150 developers. At today's rate, that's about 11.25 million spent on maintenance alone. Hmmm... I wonder what it would look like if you could turn even half of that into features?
Finally, let's talk about patterns (since patterns are an extension of code quality necessarily, since in software engineering these days, patterns emerge more than are dictated from code). A bad pattern, then, can be though of as a formalization of bad code quality (I don't use the term anti-pattern, because that takes the conversation in a completely different and pretty much useless direction). So what do we then have? I think it's obvious, but let's call it out: a highly efficient way to ensure that code quality is evenly distributed throughout new code as thoroughly as it was in old code. In other words, you magnify the problems Krugle points out in their white paper. Let's examine this. Do new developers spin up faster on the code base just because it's a pattern? No, they may not even realize it's a pattern until months after they've shipped their first feature. Is there better research and planning (because the code is easier to understand)? Also a no, because bad code quality is still difficult to understand, even if it is repeatable. Is there less duplication of effort? Again, no, because of the previous statement. The only dubious 'win' is consistency with coding standards and practices, which is questionable because are bad coding standards and practices something you want to be consistent with?
I would suggest that, once performance is consistent with user expectations (read: not the best it can ever be, just consistent with user expectations of similar applications in the space), it's time to focus on code quality before committing to additional performance tweaks. Whether it's obvious or not, the bottom line is suffering if you have poor code quality, and if you're considering punting on it because performance gains are easier (and they are just by virtue of being easily quantified), just think about what you could do with 6.125 million dollars worth of new features.
