Quantity trumps quality

Jeff Atwood relates an insightful anecdote about quantity over quality that you may initially find counter-intuitive. A pottery-making class was broken up into two groups, with one half graded on the basis of creating a single perfect pot while the other half graded on how much pottery they produced (it was literally weighed, and grades given out for ranges in pounds). At the end of the class, the group that was producing the best pottery was the group that was going for quantity, because they had created such a large number of pots that the experience they gained overshadowed the pain-staking analysis of the other group.

Naturally, there are all sorts of parallels between this anecdote and many other areas, but I’d really like to relate it to software engineering. I’ve always been a “get straight to coding” kind of guy, doing just the bare minimum of planning necessary to start coding, and then writing the documentation along with the code. And after many years of doing this, my code consistently turns out pretty well. A big reason, I suspect, is simply because this approach leads to so much coding. I write programs for all sorts of little random fun things that I would never get around to if I had to spend a bunch of time painstakingly planning out each program beforehand. The best way to become a better coder is not to plan out how to do it, it’s to actually do it, a maxim which also applies to any other activity, including pottery.

6 Responses to “Quantity trumps quality”

  1. drinian Says:

    More subtle, however, is the importance of understanding the problem before beginning to code.

    Both groups knew that they were making pots. If you don’t know if you’re making a pot or an ashtray before you begin coding, so to speak, you’re going to just end up down the wrong road altogether.

  2. Cyde Weys Says:

    Yes, true. I believe I outlined my process more thoroughly in this post, and step #1 boils down to “Understand the problem”. You’ll notice that step 2 (planning) is often abbreviated and step 3 (research) is optional, and generally happens concurrently with step 4 (coding).

  3. T2A` Says:

    This ideology is pretty damn accurate, and I’m pretty sure it explains why I basically suck at everything — premature quitting on my behalf because what I was doing at the time wasn’t good enough. Had I just finished something — anything! — I could have gotten something out of it and improved… which would then lead to starting and finishing more things with a better skill set.

    What sort of “fun” things to do end up programming? I can’t recall anything I ever programmed for fun and finished. Everything eventually seemed to reach this point where the difficulty of continuing exceeded any degree of “fun” in making the program. D:

    Example: Crappy text-based Minesweeper. The idea was to make something similar to the one that came/comes with Fedora/Ubuntu in that the first click always opens something up rather than leaving the possibility of a single useless open cell. I got that done, but when it came time to add extra features and port it over to VB/C#.NET for a UI I lost all interest pretty much immediately.

    Since then I’m pretty sure I haven’t done anything in a compiled language, and instead I tried out some web design stuff (PHP, CSS, JS, Photoshop, etc.). Now I got a job doing that stuff (as opposed to “real” programming), and I seem to learn something new every time I go to work. D:

  4. Kelly Martin Says:

    This just reiterates the bromide that you can’t fly until you’ve learned to walk.

  5. T2A` Says:

    Or that you can’t fly until you’ve walked long enough that your arms have evolved into wings in order to save your feet from certain destruction.

  6. Cyde Weys Says:

    T2A`: Considering hundreds of millions of years separated the development of legs and wings (in both dinosaurs and in mammals, not sure about insects), I don’t think that one is an issue.