@David Sidlinger:
Good point. It’s like the old question of whether someone has ten years of experience, or one year of experience ten times.
This advice goes well with this video by Ira Glass:
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.
Yeah, I agree. I work with one guy who never seems to realize there might be a better way. He even describes his coding style as Brute Force. I’ve been trying to steer him away from being a stereotypical bad VB programmer, but I’m ready to give up, I figure if he doesn’t want to change it’s not going to happen.
I’m much more into studying new languages and coding techniques. I sometimes feel bad at how little code I write, but then again I haven’t had to recode anything from scratch recently - a common theme with some of my other coworkers.
I wish more programmers would read about art, or craft, or whatever you want to call it. Lots of people are missing out on a substantial body of literature that tries to address how to use your time and tools effectively to produce high-quality work. Creative work isn’t necessarily about self-expression, but it’s fundamentally about picking up a set of tools and making stuff. In that respect, software and the arts aren’t all that dissimilar.
It’s an interesting anecdote in the work cited, however I wonder if everyone in the ‘quantity’ group fared better overall than the ‘quality’ group, and likewise did all in the ‘quality’ group fare poorer, or were some better.
What was the standard deviation in the marks of the two populations? How did the bell curves overlap?
As another poster wrote, did the ‘quantity’ group get better over time, or did they just get a few lucky good pots quality-wise.
Yes, you need to write programs in order to test your theories out. The greatest part about Computing Science is that it’s usually easy to do. You don’t need a particle accelerator. All you need is a compiler. In some ways thought, it’s the low barrier to entry that causes so many problems in this field.
But seriously, I know a lot of really rubbish coders that can churn it out like there’s no tomorrow. I’ve never seen a bad painting crash a rocket or melt down a reactor. Unless you’re truly writing useless software, the impact of bad code is percievable. Do you like it when stock-market computers lose your money vs. a breaking a pot that took a student 10 minutes to make.
In all aspects of life, how do you get people to motivate themselves to do better? It’s the only question I know I’ll never be able to answer. A known unknown if you will.
This assumes that everyone learns from their mistakes, or more importantly recognizes when they have done so.
have half the posts missed the point. This article is not saying quality is not important! It is saying that you do not necessarily get quality by spending most of your time designing and thinking up front.
The best way to get quality is to design, do and iterate. (within reason). but you cannot get quality by designing alone. you must focus on doing, testing, fixing, learning.
in my humble opinion anyway…
Apparently, quantity (the Sherman Tank) beat quality (the Panzer Tank) way back in WWII.
Has engineering run it’s course… almost.
I’m becoming a student and proponent of ‘Erlang’ … there’s new interest in this software engine due to the rise of multi-core processors. Erlang accepts that software programmers aren’t perfect and will develop buggy code. Instead of charging the programmer with anticipating all possible faults, Erlang just lets the process timeout, die, and be reborn with a shiny fresh new one. This is the fault tolerance. With no globals variables (functional programming) Erlang is highly scalable. And with the Erlang engine having two ‘slots’ for each module (old running and new running) it allows for system upgrades, corrections and improvements without a takedown/reboot/relaunch/whathaveyou. When you populate the ‘new’ slot, the stack ‘pops’ unroll from the ‘old’ stack, but the stack ‘pushes’ come from the new slot. When the old stack is drained, I suppose the new slot becomes the ‘old’ slot and the ‘new’ slot is emptied.
Has engineering run it’s course… almost. When we have mobile thinking robots (cognibots) they’ll be ‘grown up and trained’ rather than programmed. Or, both, kinda like people are today. So they’ll need psychologists more than engineers to deal with those things.
This is curious, but certainly seems to be true. The act of writing code really seems to improve the code you write.
However this this is true so long as you don’t switch your brain off while writing. I think people need to be constantly questioning whether the code they are writing is the best way to do things.
Jeff, I think you’re using the analogy incorrectly and it’s perhaps not even appropriate.
Take a computer science class. Give group A the task to write as many ‘useful’ programs as possible, give group B the task to write one (perfect) useful program.
The analogy works in this case, you will find some ‘better’ smaller programs I am sure.
However consider adding an additional task the next day which would work in software but not for pottery, tell group A to make all your programs work together, let group B continue to work on their program.
Which group’s final product will be better? I’d suggest that the result would be much more variable.
I’m more of an and person than an or person, and I’ve been saying quality in quantity for awhile — it’s so true that by amassing experience, your quantity goes up. Generally, instead of cramming every idea that comes midstream into a single project, I prefer to save ideas for future projects and build them into what I describe as a stepping-stone narrative.
Anyone who’s done ceramics know it’s better to make lighter pots, not heavier ones.
Just curious Jeff since you made the decision to leave your dayjob a little while ago (or rather, to make blogging your day job)…
Do you think that will impact your perspective on the topics you’re blogging about, I mean… since you’re no longer in practice… or doing the ‘quantity’ part.
Or do you think this quantity thing is something we need to do in the beginning, then we can plateau out?
So… anecdotes are now the basis of engineering principles?
Great article and most of the comments give great advise too 
Jeff,
just wondering if you left out a few key paragraphs there in order to get the reaction above?
I whole heartily disagree with you Jeff, and am really disappointed that you would condone such a practice. The worst thing that any programmer can do to produce better quality code is to write more sub-quality code. Although your argument seems to be if your right more code you will inevitably get better at it, this logic has an inherent flaw. This flaw is: as people learn to write code, or learn to do any activity, they will form habits that they will continue to utilize in the future. The more they do the more these patterns become ingrained, as is natural with any sort of repetitive process. To change these habits and patterns usually takes large amounts of conscious effort and time. Therefore, it is only natural that the more bad code some one writes the more bad code they will continue to produce. This is akin to the infinite number of monkeys continuously typing producing the entire works of Shakespeare fallacy. It will never happen.
On the other hand, quality is a function of process and process refinement. Specifically, this refinement should be in comparison to others with more experience and the known ability to continuously produce quality product. In the end, quality inherently requires a substantial amount of self-introspection, an ability to admit that you are not as good as you think, and the willingness/determination to change the habits that you identify as lacking quality.
A large quantity of sub-par product is just that, sub-par product. Nothing more, nothing less. Quality product may take longer to design and produce, but in the end it will last longer, perform better, be infinitely more maintainable, and lastly be substantially more testable. Sub-par code is none of these things and never will be. No amount of quantity will ever improve a sub-quality situation. If anything, it may make the situation worse due to the wasted time taken to produce it, and the increased amount of time needed to rectify the situation if it can be done at all.
I’ve been lucky enough to have been able to be an artist and developer at a professional level. I have to admit you are right, artists are not developers. Developers have 10x the ego. But outside of that deviation I see almost all similarities.
Regarding the concept, qaulity vs. quantity. I largely agree, if you allow to yourself to fall into the trap of over planning. And another trap not talked about here is the not knowing when its good enough. On open-source projects you aren’t as closely boxed into to timelines as proprietary projects. So you have time to nit-pick and go back make slight changes and continue analyzing the project to death while code is being written. That was a chapter in pragmatic daves book if I recall correctly. Know when it’s good enough.
When I build something I don’t want to resemble a McDonalds restaurant. I want to look like the old steak house downtown that is filled wood wood and brass and everyone working their wears perfect white shirts and black ties. But I also want something that works. And I realize that not everyone is impressed with wood and brass. Most of the time people are just there for the steak. Content is king.
I’m a little disappointed with the quality of the posts lately and therefore am doubtfull if quality comes with quantity.
I think your point that quantity is valuable is very valid. I would also add a caveat. In the case of the ceramics, the consequences of failure for any given pot are low. That is a great advantage.
With software projects, depending upon the situation, the consequences of failure can have a high cost.
So in the abstract, before deciding that quantity is better, the situation must always be evaluated and/or arranged so that failure is not that expensive. By staying in the low cost of failure range, great innovations can be made.
This is also one reason that genetic algorithms are so interesting.