Quantity Always Trumps Quality (2008) | Hacker News Reader

Quantity Always Trumps Quality (2008)

codinghorror.com

49 pointsbillswift14 comments

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

No one pooped the old hegelian/marxist chestnut about quantitative changes inducing qualitative changes?

That's true for any non-linear system crossing a threshold. Actually, drop non-linear, even moving on a linear scale creates qualitative change.

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.

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

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.

> Re-posts are OK.

No one was saying they aren't. Some helpful members of the community often post links to old discussions of the same article.

It's not a judgement that the link shouldn't have been posted, but rather, a way to show people who missed it what was already posted.

it's invaluable when a popular link doesn't get a lot of traction on a subsequent post.

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

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

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

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.

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.

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.

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.

Reply on news.ycombinator.com