I agree with Joel here: Bob is being unfair. Here's what I heard Jeff and Joel say when I listened to their podcast:
Quality matters, but there are other things that also matter, such as actually getting working code written. Some of us (and I've personally struggled with this for a long time) have a hard time letting go of our quest for perfection and settling for shipping code that's imperfect but works. When Jeff says that "quality just doesn't matter that much," what I took this to mean is: quality matters, but it matters less than we sometimes feel like it does. And that doesn't mean he's condoning writing crappy code; he's simply saying that we tend to overvalue this abstract concept of quality and that can have a crippling effect on our productivity.
Joel focuses on dogmatic adherence to development methodologies/principles as an example, specifically testing. I got the impression that he thinks testing is great and it has its place in the software development ecosystem. It tends to increase software quality and there are certain types of software for which it is really, really important (Jeff mentions framework code as an example). That said, taken to an extreme, testing can get in the way of getting things done... getting working code written and out the door / live on the server / whatever. It can also get in the way of modifying working code, as intentional changes to the way that code works always breaks some percentage of your unit tests, just as a regression will. And while catching unintentional regressions is great (and one of the best reasons you should unit test), constantly having to rewrite your tests every time you change the behavior of an internal class can be a real drag on your productivity. And that can be bad.
The key is to avoid being overly dogmatic in your adherence to development principles. Instead, be pragmatic and find a balance. Test enough to ensure adequate quality (whatever that happens to be for your product), but no more. Otherwise you're just doing yourself (or your employer) a disservice.
> Quality matters, but there are other things that also matter, such as actually getting working code written.
"Working code written" is setting a quality bar. Really. I've seen enough code that has omitted the "working" qualifier that I think it is worth making that point. Many developers spend far too much time erring on the side of too little quality. Not developers here, mind you; I suspect that we care enough to tend to err the other direction. I mean the type that Jeff and Joel repeatedly point out who will never visit sites like this or StackOverflow.
> Joel focuses on dogmatic adherence to development methodologies/principles as an example, specifically testing.
And I think Bob is focusing on people with a complete lack of methodologies and principles. The problem is that they are both talking in greater extremes than are necessary for the sake of emphasizing their point. For what it is worth, I think they are both right, and are violently agreeing on the same gray area.
FWIW, Jeff and Joel strike me as intelligent enough developers that they likely keep their code sufficiently clean without having to consciously remind themselves, or have someone else remind them. Their subconscious quality bar is sufficiently high that they don't have to consciously think about that either. They both seem to have a sense of design that most developers just don't. So does Bob.
I suspect that Bob has worked with or heard of enough developers who don't that he feels compelled to advocate his position with a little more gusto. But both took the other's position as an attack against their own ability or philosophies; this wasn't the point. I think Joel/Jeff were addressing the people who have the tendency to care about what they do, perhaps a little too much at times, and convince them to let go a little bit; Bob is address the people who don't give a crap, and trying to give them a least somewhat of a mental framework to make things that at least kind of work most of the time. The problem is that these people need things told to them dogmatically, to get them out of their comfort zone. That kind of dogmatic advice tends to rub those who think about what we do to begin with the wrong way.
Quality matters, but there are other things that also matter, such as actually getting working code written. Some of us (and I've personally struggled with this for a long time) have a hard time letting go of our quest for perfection and settling for shipping code that's imperfect but works. When Jeff says that "quality just doesn't matter that much," what I took this to mean is: quality matters, but it matters less than we sometimes feel like it does. And that doesn't mean he's condoning writing crappy code; he's simply saying that we tend to overvalue this abstract concept of quality and that can have a crippling effect on our productivity.
Joel focuses on dogmatic adherence to development methodologies/principles as an example, specifically testing. I got the impression that he thinks testing is great and it has its place in the software development ecosystem. It tends to increase software quality and there are certain types of software for which it is really, really important (Jeff mentions framework code as an example). That said, taken to an extreme, testing can get in the way of getting things done... getting working code written and out the door / live on the server / whatever. It can also get in the way of modifying working code, as intentional changes to the way that code works always breaks some percentage of your unit tests, just as a regression will. And while catching unintentional regressions is great (and one of the best reasons you should unit test), constantly having to rewrite your tests every time you change the behavior of an internal class can be a real drag on your productivity. And that can be bad.
The key is to avoid being overly dogmatic in your adherence to development principles. Instead, be pragmatic and find a balance. Test enough to ensure adequate quality (whatever that happens to be for your product), but no more. Otherwise you're just doing yourself (or your employer) a disservice.