Ah, the hacker mentality. Keep on trying until it works rather than
spending some time to leaf through a manual and implementing a fix
for the problem in less than five minutes.
Reading comprehension impaired, are we?
Fire and motion (Joel)?
One of the things my art teacher taught is to work in series. By the end of a series of twelve paintings of variations on the same scene I noticed a dramatic improvement. The first painting was crude and the last paintings were lively and interesting.
You will not know whether an idea is good until you try it. The shortcomings in an experiment will spark ideas for what to try next.
Programming is a tool as a pencil is a tool. Just as you can use a pencil to make either a shopping list or a fine drawing you can use write a program for a mundane purpose or in pursuit of higher objectives that may have some of the characteristics of Art.
Hi Jeff,
I agree that trying more tends to bring out the best work. But when you donât have the luxury of time to work on everything, you got to pick and choose your battles. You canât fight on all fronts. You got to pick the battle with the best payoff.
This example really has nothing to do with writing good code. As other comments have noted, you canât write a bunch of crap and get away with it. Where will all of this bad code go? Thatâs right, straight to the client.
In software development we have a thing called code reviews. We have to learn and correct our mistakes before a final product is released. We donât write disposable code.
I now agree with that, quantity lets you get better at quality. By quality I mean what ever metric you measure your project against?
My last job was very frustrating, I always had the feeling that they just wanted to push as much business out the door as possible. I never felt I had time to work on the quality of the software I was creating. Only after leaving and getting a break from that place was I able to see that the quality was actually improving. Over the course of the time I worked there crashes and pages to on-call folks went down. The quality improved because with every crash and error page that went out I did not just fix the issue at hand, I tried to fix the underlying problem and/or add in better error handling. It felt like all I was doing was putting bandaids on the problems (and sometimes that is all it was) but really I was making the quality better.
If I ever go back to that old job I would approach it with a much different viewpoint and I donât think I would have as much frustration.
That sounds like the advice Microsoft gave its developers when they wrote vista. More is better didnât work out to well for them, doubt it does for you either.
From a business perspective, that is the worst you can ever do. If you release a lot of bad applications you will get a reputation of developing bad applications, and you will not sell anything.
I agree that the fundamental idea of learning from your mistakes is a good thing, but I think itâs more important to learn from other peoples mistakes.
Some of you guys need to read up on the difference between skill and knowledge. Iâll give you a hint, skill involves a lot of hard work.
You really canât make 1000 tons of crap anything more than 1000 tons of crap, you know. Quantity is one way to learn quality, but itâs not really quality in and of itself.
What you seem to be saying is that one needs lots of practise, and I canât argue with that. But thatâs practise, not production code. Iâve seen far too many totally ridiculous problems arise because people were more concerned with making many things than with making the right things, and not just in software. Sometimes, a little perfectionism can go a long way - a distance that would take far more time by trial and error.
@Thomas Winsnes : I donât think weâre talking about releasing tons of software or even versions to the public.
Well, I guess this misunderstanding will go on and on in comments below 
We could just sum up the storry with three words: learning by doing.
Practice only makes perfect if you know enough to at least attempt to practice perfect technique. Trial and error is too inefficient a strategy to discovery perfect technique. Progression from beginner to journeyman to master requires study of master material and/or master mentoring. I think it takes at least 10 years to get really good at anything significant. And much longer to become truly exceptional. And thatâs with the benefit of master role models to follow.
I think this is a complete load of rubbish. You are massively over generalising if i only know a few basic approaches to a solve a problem no matter how many times I attempt to solve the problem I am going to do it in a similar way, I will only reach the best within my current skill set improving only slightly each time. If I learn new techniques by reading, theorizing or learning from others I am going to improve in other ways, usually that apply more generally to all programming not just the current problem.
You canât simply say quantity is better than quality or vice versa it is as with most things a balance.
You have also picked a quote from a ceramics class that implies it is a beginners class. Of course quantity is important at first in programming we all remember our first hello world, loops, methods, classes and recursion programs. But then to improve my programming ability past these basic constructs I have to do the quality side learning about advanced features that are often language specific.
Learning through practice only works if the developer is aware that heâs supposed to be learning, and thatâs the tough nut to crack. Just writing a lot of code is not going to help someone that doesnât even know there is a better way.
That being said, I think youâre right, Jeff. Getting in there and doing it is the absolute best way to learn anything.
All well and good, as long as some PHB isnât there to scream ship it! before youâve worked through all the poor quality code/pottery and started producing the good stuff. And that you donât have to cope with the problem of disposing of 1000 tonnes of second-rate crockery 
As others have said, practice makes perfect, donât be afraid to fail. Iâd add the story of the Buddhist archer who smiles each time he misses the target, because he knows heâs one shot closer to making the bullseye.
One fundamental issue with this approach is that it assumes the person in question has the intelligence to learn from the mistakes they make and the insight to see their issues and ways to improve things [and then put them into action].
No matter how many thousands of five-word sentences you write, if you never mix things up, step back for a couple minutes or expand your efforts a little, youâre probably not going to get very far as a writer. Or maybe I should just put it this way instead: If youâre not working with quality ultimately in mind, youâre not going to hit it, no matter how large the quantity becomes.
Learn by doing, definitely, but âquantity over qualityâ is a bit over-simplistic and somewhat a misnomer.
The pottery story is persuasive, but proves nothing.
You can disprove an assertion with a single counter-example, but you canât prove a positive assertion with a single analogous example.
The crucial lesson here is to test, experiment, push the boundaries and most importantly,learn from mistakes. That doesnât necessarily follow directly from raw quantity. By selecting for quantity, youâre applying no pressure to improve, even though it might occur as a by-product, in those students who were already primed to strive for perfection in their work. This merely demonstrates that some students had implicitly learned the lesson before they had even walked in the door, and they were being used to give a lesson to the other students. In a group of students that were purely looking for the best grade, there might have been a different result.
Great post Jeff, as usual. I think it can be summed up as:
Donât be scared to fail.
In my own experience, projects that get stuck in design because they have a lot riding on them, have a much poorer outcome generally, than projects that have less riding on them, and this can be started/restarted as necessary.
In other word, suck and see.
Actually this is partly what I do.
@Jan: Or should we call it: Practices make perfect
Though, as a note to everyone including myself, please do those practices at home, donât do it with your production code.
The interesting part is, those ceramic course students wonât be able to produce a better pot unless they notice what went wrong with their previous ones. Is it as easy to tell the bad code from the good one as we do with pots?