

Quantity Always Trumps Quality (2008) - billswift
http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html

======
billswift
Posted when it was new 973 days ago. Decent comment thread there.
<http://news.ycombinator.com/item?id=265520>

~~~
kaib
I disagree with the tone of your comment. The book cited in the article, "Art
and Fear", was first published in 1994. Having read both this article and the
original book I strongly argue that neither has lost relevance over time. Re-
posts are OK.

~~~
lucisferre
He was just linking to the original thread for people to read it. There was no
"tone".

~~~
geebee
I didn't find any negative tone to your post either. It was pretty matter of
fact.

I'm glad this was reposted, since I wasn't aware of the original link (even
though I do read coding horror every now and then), and thanks for posting the
prev discussion thread.

This post makes me feel better about my horrendous code from 10 years ago. I
was learning, and maybe this was the best way to go about it? I think almost
all programmers go through a period where we produce huge volumes of software.
There's one big difference, though. In a ceramics class, nobody has to
maintain your mountain of crappy plates, vases, and ashtrays.

------
lucisferre
I agree in general with these premises:

1\. Stop theorizing.

2\. Write lots of software.

3\. Learn from your mistakes.

However I completely disagree with the conclusion that quantity _always_
trumps quality. Seems to be a lot of blog posts showing up on HN lately that
make fairly bold conclusions in the title, which are then supported weakly by
simple premises that most rational people will agree with. They then quickly
jump straight to the conclusion without showing how they got there.

First problem is obviously the word _always_. I don't think I have to explain
the red flag there.

Assuming instead we actually mean to say, "in general quantity is more
important than quality," lets see if we can make that argument from the above
three statements...

Getting to work quickly, building some prototypes, writing some quick code to
test our assumptions, or using other techniques (my preferences is TDD) to
learn through the act of actually building software is undeniably a good idea.
I'm sure 90% of us here agree that this is the best way to accomplish this.
However, we also know that along the way we are going to produce some badly
written software (that still basically does what we need) and are going to
need to improve it's quality if we want to keep building new features,
extending and maintaining it.

Quantity does not absolutely (or even generally) trump quality in practice.
They are logically related in a balance that deserves to be recognized, and
that balance should be considered and applied to the software design by people
who actually understand how the tradeoff affects it.

A good article to read on internal quality tradeoffs is here:
<http://martinfowler.com/bliki/TradableQualityHypothesis.html>

Some more MF stuff on Technical Debt in general
<http://martinfowler.com/bliki/tags/technical%20debt.html>

A short explanation is that quality is very relevant, particularly over time.
Prototyping with quick, poorly planned or designed code in order to learn
before committing to a final design is a good idea if (and only if) we are
willing and able to throw most, if not all, of the prototype code away at the
end and only keep what we've learned from the process.

Of course, I won't make that argument that quality is _always_ important. I'm
not willing to get into absolutes territory here. I will however gladly argue
that it is usually important.

------
bediger
As Stalin once said (<http://en.wikiquote.org/wiki/Joseph_Stalin>), "Quantity
has a quality all its own".

~~~
lucisferre
Stalin was also convinced that planting crops closer together would yield
better results since they would 'cooperate' rather than compete. He was not
exactly a pillar of deep thinking.

<http://en.wikipedia.org/wiki/Trofim_Lysenko>

~~~
bediger
Even a blind pig finds an acorn once in a while.

------
cafard
So Louis L'Amour is the greatest American novelist of the last century. Well,
at least one U.S. president thought highly of his novels.

------
suprgeek
Absent some form of Directed Feedback/Learning you could just end up with a
large number of equally low quality software. The only way that Quality would
emerge would be by sheer dumb luck.

As usual the title and the intent of the post is wildly simplistic. Quantity
almost never trumps Quality without direction.

------
PaulHoule
High volume makes high quality both possible and necessary.

If a company sells 500 $500,000 sports cars a year, it isn't going to have
much information about problems that happen at the 1:1000 level. Toyota, on
the other hand, is able to think about problems that go wrong at the
1:10,000,000 level with Corollas.

This is why the "six sigma" label makes some sense... Big corporations really
work on a scale where problems at the six sigma level really turn up
regularly.

