This idea is captured nicely in the book "Art and Fear" with the following anecdote:
"The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality.
His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot – albeit a perfect one – to get an “A”.
Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work – and learning from their mistakes – the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay."
David Bowie and Tin Machine used this technique on their album Tin Machine.
>The Sales’ also pushed for a punishing first-take philosophy, which Bowie found enticing. No overdubs unless necessary for guitar solos, no synths (the old Queen boast), and most of all, no lyric rewrites. The band would go to lunch and return to find that Bowie had written out a complete provisional lyric for whatever song they were working on. But that was as far as he was allowed to go: he was forced to keep to his first instincts. Sometimes this worked out, sometimes it didn’t (see “Crack City”).
>Given these strictures, Bowie and the band stuck to music “that didn’t have too much orchestration about it,” as Bowie said in a 1989 interview. “If it got too chordy and arranged, it wouldn’t be anything what we wanted to do. The structure had to be as loose as possible so that we could improvise.” Rather than reworking songs, they just kept cutting more, with as many as 35 to 40 pieces coming out of the sessions. So most of Tin Machine is basic blues-centered rock, with the average song having no more than five chords: it lacked the harmonic ambiguity and structural games of Bowie’s older work. While the record often worked on a song level, with 14 tracks on the CD version, the album was a wearying listen. Few records are as exciting in miniature and as draining as a whole as Tin Machine.
I can’t remember the name of the ceramicist, but hearing him interviewed on Radio 4, his apprenticeship in (China|Japan) involved every pot he made being deliberately smashed at the end of the day for a year. A way to get over a fear of failure and to learn to keep repeating the process of learning.
I don't find it now, but I've read that anecdote is made up. And I don't think it make sense. Except for when you are an absolute beginner, you won't improve if you don't put in any effort in the quality of your work. See deliberate practice etc..
No, the point of this anecdote is that you get good at quality by pursuing quantity.
It's an appealing idea because it's counterintuitive, and here on HN were are absolute suckers for contrarian ways to outsmart the herd. But we have been given no reason to think it actually works.
Well, in writing terms, it seems to have worked for Ray Bradbury:
> The best hygiene for beginning writers or intermediate writers is to write a hell of a lot of short stories. If you can write one short story a week—it doesn’t matter what the quality is to start, but at least you’re practicing, and at the end of the year you have 52 short stories, and I defy you to write 52 bad ones. Can’t be done. At the end of 30 weeks or 40 weeks or at the end of the year, all of a sudden a story will come that’s just wonderful.
... incidentally, also Neil Gaiman's advice in the Masterclass lectures.
The reason it works so well for writing is, as Neil Gaiman points out, that if you work for a year on one story, you've probably practised starting a story 52 times. But you've still only practised finishing a story once. And getting into the habit of finishing things is one of the most important habits to get into.
I understand the point they are trying to make, but I still think the anecdote is harmful. It gives the impression that it is more important to put in the work than any real effort. The only thing you’ll be good at after producing 1000 crappy pots is producing crappy pots.
I think you are over-simplifying the situation. Malcom Gladwell's book Outliers popularized the notion that a person needs on average 10,000 hours of practice to truly master a given task. A lot of people took this to mean, "if you put in 10,000 hours of practice, you will become a master." This is not true. The 10,000 hours of practice is necessary, but not sufficient. The practice has to be _intentional_, guided, goal-oriented practice. Not just playing the same song or making the same shot over and over.
That was exactly my point. It is harmful to believe that mindless practicing, or pottery, will make you a master just because you put in the time or prescribed number of pots. How am I oversimplifying?
It's also tinted by the fact that learning a skill is usually logarithmic. If you are a student with no pot-making skills, those first few pots are gonna give a lot of XP. I think it'd be a different outcome if done with more experienced potters.
Maybe this works for potters but I don't think it'd work for developers. If a compSci lecturer suggested one group would get an A for writing a perfect, bug free app and the other group would get an A for writing 50,000 lines of code, I wouldn't expect the group writing as much code as they could to make the best app.
Knuth suggests, in TAOCP, that the best way to write a program is to write it once, scrap it completely and rewrite from scratch. Very much in line with spending an entire semester making one perfect program vs spending a semester writing and rewriting new programs from scratch.
I used this extensively for code assignments in university, but for a different reason. We had to do most things in C, which can be very painful for prototyping and experimenting with new approaches. So I would solve the problem first in Python, try different approaches, and then after I was happy with the solution I'd write it again in C. Saved me a lot of time in the end.
A better approach in my experience is to grow the whole system from a “skeleton” implementation, refactoring the architecture and code as your understanding grows. With the key use cases being your guide.
In the pottery example Group A were marked by weight ("fifty pound of pots rated an “A”, forty pounds a “B”, and so on."). Making a single giant pot could get you an A if the lecturer wasn't pedantic about the meaning of "pots".
I think it does work for developers. You also learn programming by doing it, rather than by thinking about it. Write 50 apps, and your 50th is bound to be better than if you start out trying to write the perfect app on your first try.
I think if doing this I would have a group split so one has to create an app that's finished (defining that would be fun) and one that has to write one that's code is 'clean' (again, fun defining that).
I say this because I've worked with a lot of inexperienced developers that commonly have a stack of half finished projects, or things they've re-written half a dozen times to get the architecture right. I'm my experience you learn a lot by finishing things, and being constrained by previous decisions.
Bonus points if you can get customers relying on your work, nothing motivates like support emails.
Consider someone with little to no experience with programming trying to build a single app and planning it out and refactoring and refining it continuously, compared to constantly creating and archiving multiple toy prototypes of the same app and then considering the best among those.
(The app's size and complexity should be commensurate to a single clay pot in a ceramics course.)
It requires the students to actually try to make something of quality, sure, but only to the same degree that the students in the original (apocryphal) story did- after all, those students could easily have shown up with a pile of baked misshapen clay instead of proper pots.
in the extremes, neither of approaches work, if you are just fighting yesterday's bugs or paralised by choice and perfecction, both are bad ideas.
It's like order and chaos, what you want is to find a balance that allows you to explore, and leave things a bit open so they can also be extended, but also sound and precisse enough so that it actually works, and does the job.
In this hypothetical scenario, instead of counting final lines of code, maybe we should count lines of affected code: take each commit and count how many lines were added, modified or deleted.
That matches "the quantity trumps quality" idea above more closely in our industry.
"The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality.
His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot – albeit a perfect one – to get an “A”.
Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work – and learning from their mistakes – the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay."