TL;DR: More quantity leads to more feedback. More feedback leads to more learning. More learning leads to better quality.
With the beginning of the new year, I decided to start a “One Project per Month” challenge on GitHub. The idea was to accelerate learning, avoid over engineering to develop a habit of getting things done. However, some people doubted that there could be a substantial outcome from “one month” projects and idea sparked a lively debate on Hacker News.
In these comments, I came across a story that appeared in Jeff Atwoods highly recommended “Coding Horror” Blog. It’s about a ceramics teacher, who does an experiment to see whether focus on high quality or high quantity would yield the better results (originally it’s from the 2001 book Art & Fear):
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.
So, without the perfectionism and the overthinking the quantity focused group produced better results. However, putting quantity before quality still seems counterintuitive, especially in the world of software engineering. Thinking about this theory I saw some potential for misinterpretation and false dichotomy thinking. In the end, I came up with three possible misconceptions that I’m going to explain in more detail.
The first one is the the “statistics misconception”. One could think that the quantity approach won just because it produced a larger result set. When selecting the best examples from a larger set, it seems more likely to find works of high quality.
What this idea implies, is that the variations between the pots are random. Now, the interesting thing is, that this is actually true for the “high quality” group, but not for the “high quantity” group. With the “high quality” approach, the students followed the best strategies they could come up with, based on their individual past experiences. Some of these strategies yielded good results, others didn’t. In the end, it was random. When you keep in mind the high numbers of projects that fail, this seems even more plausible.
On the other hand, in the second group, each student executed several iterations. And while they started with each new pot from zero, they gained more and more insights in what it takes to produce good pots. In the end, they did not only know how to produce high quality pots, they could also do it faster than the group with the big plans that avoided fresh starts.
Get Gerhard Görlich’s stories in your inbox
Join Medium for free to get updates from this writer.
The second misinterpretation, is that speed kills. In this matter, I’m with Jeremy Clarkson:
“Speed has never killed anyone. Suddenly becoming stationary, that’s what gets you.” — Jeremy Clarkson
It’s a mistake to equate speed with frequency. Sure, if the speed of a factory line is gradually turned up, the quality will suffer at some point. But in an assembly line, the process is fixed, clearly defined from the beginning and will stay the same for each item. Factory line processes do not involve any learning or creativity (at least not in short time scales).
In a creative process, you have to define the process steps by yourself. At any point, you can decide to get some feedback, try a different strategy or start all over again. The artist gets permanent feedback how his actions affect the result and whether or not they brought him closer to his vision. So the difference to the factory line is the frequency of the feedback, not the work pace.
This may also explain why management strategies developed in the early 20th century are having so much trouble adapting to today’s increasingly knowledge based economy. In complex, knowledge based workflows, it’s simply not possible to plan everything in detail upfront, because the work itself creates insights that affect the upcoming steps.
Finally, there is the “arts and crafts” misinterpretation. In crafts, an expert can usually create a detailed plan upfront to reach a clearly defined result. In arts, the result can and should be unpredictable. So here we end up once more at the age old question: is software development an art or a craft?
In my opinion, this question is an attempt to apply static concepts to dynamic processes. It’s been around for so long because it is inherently flawed and therefore will never be clearly answered.
A musician, in example, has to study and practice for years to develop virtuosity. He is playing scales, correcting mistakes, improving technique and finally develops his own style and creativity. But performing his art on stage is actually mostly a craft. The spotlight is not the place to be creative (although some music styles like Jazz deliberately broke with this principle).
So some developers consider themselves as artists while others claim to be craftsmen. I think healthy teams need both types. A good example for this difference is a quote from an engineer I read a while ago:
“If you want to shoot yourself in the knee, I will make sure that the bullet gets there in the most reliable and effective manner” — unknown source
While quality delivery of a bullet is a perfectly valid request to an engineer, the artist will revolt and eventually react in unpredictable ways. Like starting a maker club in his Christmas vacations or something.
These, among other thoughts, led me to start the “One Project per Month” club. An online community for makers, hackers, writers, builders, creatives and entrepreneurs. It’s about accelerating learning, avoiding over engineering and getting things done.