In a recent StackOverflow podcast, Jeff Atwood had this to say about code quality
Jeff: Right. The longer I think about this, the less I care about code hygiene issues (laughs). Because the unit of measure that really matters to me is, how quickly you can respond to real business needs with your code. And by that I mean, how well are you serving the people that are using your code. To me that’s what it’s all about. Anything that gets in the way of you fixing your code or improving your code in a way that your customers can appreciate, is a negative. If that means using Ruby, or having lots of unit tests: whatever’s working for you: do that. But if it’s getting in the way, if it becomes friction, like, “I’d love to have this great new feature but I’d have to have 1000 unit tests,” that’s a negative.
Joel: Yeah. And the worst thing that happens is that you get people that just stop thinking about what they’re doing. “This is the principle, to always write unit tests, so I’m always going to write unit tests,” and then they’re just not thinking about how they’re spending their time, and they wind up wasting a lot of it.
Jeff: Yeah, it’s a balancing act. And I don’t want to come out and say I’m against [unit] testing, because I’m really not. Anything that improves quality is good. But there’s multiple axes you’re working on here; quality is just one axis. And I find, sadly, to be completely honest with everybody listening, quality really doesn’t matter that much, in the big scheme of things… There was this quote from Frank Zappa: “Nobody gives a crap if we’re great musicians.” And it really is true. The people that appreciate Frank Zappa’s music aren’t going, “that guitar was really off.” They’re hearing the whole song; they’re hearing the music, they’re not really worried whether your code has the correct object interfaces, or if it’s developed in a pure way, or written in Ruby or PHP… they don’t really care about that stuff. We do internally, but it’s important to balance that, I think, and I think that gets missed a lot, which is, maybe, the point you’re getting at.
A friend forwarded this response from Robert Martin who was the unwilling target of some of the tirades by Jeff and Joel against object-oriented design principles and unit testing:
he [Jeff] said that lately he had been getting less and less concerned with code hygiene. So possibly he was trying to say that code quality just doesn’t matter that much.
But that doesn’t make me feel any better; because one thing you learn after four decades of coding is that code quality matters one hell of a lot. So to respond to Jeff I’ll simply fall back on the old saw “Faithful in little, faithful in much.” In other words, if you can’t keep your code clean, no way can you keep your systems clean.
[…] You see, I think quality matters. I think the quality of my code matters, even at the smallest scale. I think the quality of my systems matters. I think the quality of my tests matters. […]
Martin has a point about code quality and was right in correcting Joel’s misconceptions. But I think we need to consider a few facts:
- Whatever Jeff and Joel are doing for StackOverflow and FogCreek seems to work fine for them. Of course, we don’t know how well they think they are meeting business needs, but apparently both seem to be okay with the quality of the applications they have created.
- Both of them have been advocates for good software practices on their blogs. So, clearly this is a case of “Those who drive faster than me are maniacs and those who drive slower are idiots”. It is likely that they will move towards stricter quality practices as the number of users, programmers and application functions grow.
Also, quality of code at the “smallest scale” cannot be an absolute principle. When writing any software, you have to prioritize the level of quality with the resources that you have. You can write increasingly higher quality software, but it will cost you: money, time, effort, and opportunities. You also have to consider marketing needs such as releasing more features, releasing faster than your competition and releasing according to external schedules, such as an application timed to release with the Super Bowl.
Code quality, by itself, matters little. It only matters in the context of both short-term and long-term business benefit. Short-term means avoiding things that would slow down programmers from delivering features. Long-term means reducing the debt incurred by the project that results in money spent on unwanted and difficult maintenance. The right methodology that works best for the short-term and long-term can vary for different teams and different companies.