6 ms·

Quantity Always Trumps Quality (2008)

49 points by billswift 16y ago

billswift 16y ago
Posted when it was new 973 days ago. Decent comment thread there. http://news.ycombinator.com/item?id=265520 http://news.ycombinator.com/item?id=265520
- shithead 16y ago
  No one pooped the old hegelian/marxist chestnut about quantitative changes inducing qualitative changes?
  - ovi256 16y ago
    That's true for any non-linear system crossing a threshold. Actually, drop non-linear, even moving on a linear scale creates qualitative change.
- kaib 16y ago
  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 16y ago
    He was just linking to the original thread for people to read it. There was no "tone".
    - geebee 16y ago
      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.
  - chollida1 16y ago
    > 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.
  - deleted 16y ago
    [deleted]
cafard 16y ago
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 16y ago
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 16y ago
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.
bediger 16y ago
As Stalin once said (http://en.wikiquote.org/wiki/Joseph_Stalin http://en.wikiquote.org/wiki/Joseph_Stalin), "Quantity has a quality all its own".
- lucisferre 16y ago
  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 http://en.wikipedia.org/wiki/Trofim_Lysenko
  - bediger 16y ago
    Even a blind pig finds an acorn once in a while.
Lambent_Cactus 16y ago
This makes me somewhat more favorably disposed to the Programming, Motherfucker paradigm. http://programming-motherfucker.com/ http://programming-motherfucker.com/
lucisferre 16y ago
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 http://martinfowler.com/bliki/TradableQualityHypothesis.html Some more MF stuff on Technical Debt in general http://martinfowler.com/bliki/tags/technical%20debt.html 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.

49 points by billswift 16y ago

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

shithead 16y ago
No one pooped the old hegelian/marxist chestnut about quantitative changes inducing qualitative changes?
- ovi256 16y ago
  That's true for any non-linear system crossing a threshold. Actually, drop non-linear, even moving on a linear scale creates qualitative change.
kaib 16y ago
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 16y ago
  He was just linking to the original thread for people to read it. There was no "tone".
  - geebee 16y ago
    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.
- chollida1 16y ago
  > 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.
- deleted 16y ago
  [deleted]

cafard 16y ago

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 16y ago

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 16y ago

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.

bediger 16y ago

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

lucisferre 16y ago
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 http://en.wikipedia.org/wiki/Trofim_Lysenko
- bediger 16y ago
  Even a blind pig finds an acorn once in a while.

Lambent_Cactus 16y ago

This makes me somewhat more favorably disposed to the Programming, Motherfucker paradigm. http://programming-motherfucker.com/ http://programming-motherfucker.com/

lucisferre 16y ago

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 http://martinfowler.com/bliki/TradableQualityHypothesis.html Some more MF stuff on Technical Debt in general http://martinfowler.com/bliki/tags/technical%20debt.html 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.