

Uncle Bob's rant on Jeff and Joel - abyx
http://blog.objectmentor.com/articles/2009/01/31/quality-doesnt-matter-that-much-jeff-and-joel

======
jd
The podcast covers unit testing and code quality at 45 minutes in or so. I
haven't listened to the entire podcast, so I may have gotten this wrong, but
it seems like Joel and Jeff made only nuanced statements. No unqualified
remarks like "testing is bad" were made, I think.

Joel and Jeff mention that code quality doesn't matter much from a _business_
perspective. In Jeff's case - does the code quality of StackOverflow's
internals matter? Probably not. There's no critical information there - so
security is not an issue. It makes sense to me that time spent on features is
going to be appreciated more by the users than time spent on code quality.

As for the unit tests - I don't think they mean to say that unit testing is a
waste of time in general. From what I understand they're saying that unit
testing isn't "real actual work". You write unit tests to save yourself
debugging and regression testing effort later. If you consider unit tests
intrinsically valuable you may end up writing tests for every getter and
setter, and that's just a waste of time. They also mention that unit-tests
themselves have to be maintained and updated, and if architectural changes
break a significant percentage of unit tests then you have to put a lot of
effort in fixing your tests.

The .NET framework was even mentioned as an example where high code quality is
incredibly important and where all interfaces should be extensively unit- and
regression-tested by Microsoft.

> I’m starting to wonder if anyone should be using any of their products.

So happy users of Fogbugz and StackOverflow should leave because Joel and Jeff
are too pragmatic?

~~~
azanar
> From what I understand they're saying that unit testing isn't "real actual
> work". You write unit tests to save yourself debugging and regression
> testing effort later.

This sent off my faulty logical implication detector. Assuming that debugging
and regression testing are work, doing something that isn't work right now to
avoid having to do something more tedious and time-consuming that is work
later on seems like a good trade-off to me. This seems like splitting hairs
over the definition of work, and worrying about semantics rather than the end
result.

> Joel and Jeff mention that code quality doesn't matter much from a
> _business_ perspective.

Yikes. This reasoning scares me. I can understand the business not caring
directly about the quality of code, in that people working from that
perspective would go in and start doing code reviews. But indirectly the
implications are huge, and any business man who would claim not to care about
the code base is really saying to me they don't care about the longevity of
their business. The success of the business is directly tied to the ability of
the developers to continue making things that people want, and this is way
easier and faster when they aren't consistently confounded by the code.

------
spolsky
I'm pretty sure Uncle Bob is misrepresenting what we actually said, so I
transcribed the ten minutes or so from the podcast that he's upset about here,
so you can judge for yourself:

<http://www.joelonsoftware.com/items/2009/01/31.html>

~~~
brentb
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.

~~~
azanar
A couple of points here:

> 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.

------
wyday
"Uncle Bob" doesn't provide any really provide proof for his argument any more
than Jeff & Joel did. He says "The vast majority of the code I write, I write
test first. (And no, Joel, this isn’t a waste of my time.)"

But how do you measure wasted time. Or conversely, how do you measure success?

Jeff and Joel have in the past measured success by user base size and profit.
"Uncle Bob" doesn't define success or good use of time.

------
kungfooey
#38 was the first podcast I had listened to, and before doing so, I had not
heard of Uncle Bob. Now having read his blog post, he comes across as a pretty
sour fellow with a bone to pick. As others have pointed out, his nitpicking at
this particular statement is not very fair. He also implies that J and J give
bad advice and shouldn't be trusted with your business, which just reinforces
the idea that they guy maybe just has a chip on his shoulder.

He appears to be selling his services as a consultant, so it makes economic
sense for him to belittle his free "competitors" with this sort of nonsense. I
don't buy it.

------
steven512
I agree with Joel's position wholeheartedly. I've read Robert Martin's book
"Agile Software Development, Principles, Patterns, and Practices". Referring
to the book, which demonstrates the SOLID principles, it's not that you can't
do it that way and be successful, it's that a pure object oriented approach is
not necessarily the best approach to building every kind of application. He
says in his book regarding an example implementation of a payroll system, that
we are paid to create "behaviors". I disagree. This detailed critique explains
it well:

[http://objectmix.com/theory-concepts/10776-critique-
robert-c...](http://objectmix.com/theory-concepts/10776-critique-robert-c-
martins-agile-principles-patterns-practices.html)

------
Encosia
Bob's discussion of the SOLID principles on Hanselminutes (which is what Jeff
and Joel are referencing) was pretty good.

Jeff and Joel started by talking about the Bob interview, but then went on to
criticize the dogmatic types more in the abstract than directed at Bob. At
least that's how I took it.

Seems like their arguments and rebuttals crossed in the mail. Nothing to see
here.

