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 c

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.