In his post Quantity Always Trumps Quality, Jeff Atwood made a very interesting reference to an arts-related book:
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.
If I tell you that you’ll get better at doing something if you do it repeatedly you’ll probably stare at me with a look of obviousness, but even then the correlation made above still feels a bit surprising to a lot of people. Why is that so?
I have a guess. In our society we tend to believe that art and innovation is something for the gifted, rather than the product of hard work. Just think of any great famous painter or musician and you’ll likely have in your mind the concept of a uniquely gifted genius, rather than someone that worked uniquely hard after a goal.
Perhaps that’s why we tend to forget long learned lessons. Some 23 years ago Frederick Brooks already pointed out in The Mythical Man-month that we should plan to throw away the first version of the software, because it most likely will be a poorly designed prototype that provides insight into the problem for the actual production version. Even then, it’s still rare to see the practice intentionally in use nowadays.
I think you make a very good point. Setting a regular schedule to write code, music, paint, or do anything creative is a must.
You hit it on the head. I am a self taught programmer from about age 10 and I have written so much code I have literally forgotten most of it by this point. I sometimes get the question from young programmers “what should I write” and I usually tell them it doesnt matter because you arent going to finish anyway, you are going to write it until you get bored learning what you wanted to learn, and move on to the next interesting thing. They usually look at me confused but its the truth. It doesnt matter what you write at that level and you shouldnt worry about finishing the worlds best program.
All that matters is you write, write, write, write, write, write, and then write some more.
People dont really like that answer……
Although I fully agree with you, I think that Brooks’s famous advice ‘plan to throw one away, you will anyhow’ has been incorporated by most Agile development processes. This mean that if you are using an Agile development process you may consider not doing a specific prototype, because you will likely start your development by building one.
The advice seems to be more important for those who are still in the waterfall age.
the “War of Art” is a good book on overcoming Resistance,
which is what people usually face when beginning something…
Here are 2 nice quote from it:
=====
Someone once asked Somerset Maugham if he wrote on a
schedule or only when struck by inspiration.
“I write only when inspiration strikes,” he replied.
Fortunately it strikes every morning at nine o’clock sharp.”
That’s a pro. (p64)
=====
Why have I stressed professionalism so heavily in
the preceding chapters? Because the most important
thing about art is to work. Nothing else matters except
sitting down everyday and trying. Why is this so
important? Because … [when we do that] … something
mysterious starts to happen. … heaven comes to our
aid. [Professionalism or Artist’s Code or
Warrior’s Way is] an attitude of egolessness and
service. (p108)
=====
Hey Capitulino,
I don’t recall this being a documented part of any of the agile processes I’ve read about. It’s slightly different to embrace change, which is indeed advocated by them, and to design a system with the goal of learning about the problems at hand.
I may be wrong, of course. Do you have any pointers to documentation of the common agile methods which indicate something similar?
In the team I’m part of, for instance, we have pretty much trashed and rebuilt a system once, but this wasn’t planned and it took some time to understand that it was an issue, and to accept that it was needed.
Well, I’m not surprised that the idea of building a prototype and then trowing it away didn’t catch… Can you convince your boss that you should work one or two months in a problem and then throw away the result of your labour?
I agree that it’s a very good practice and will doubtlessly make your final software better designed. But that’s not what the corporate world wants. They only want something that works good enough (with surprisingly low criteria for “good enough”) so that they can sell it. They don’t even care if the codebase is maintainable. They’ll just keep throwing more developers at it if it isn’t.
Software companies care a bit about good design, and try to get it right. But only to the extent that it doesn’t get in the way of their tight schedule and short budget.
My theory: Paul Graham, on taste, has pointed that “good design looks easy”. Good code looks easy. You sit down wanting to write good code and quickly it develops into a Big Ball of Mud. You give up in despair, because you thought it’d be so simple and how come you just committed all the sins everyone says programmers should stay away from.
The only way out this trap is acknowledging that simpler is harder, is to detach yourself from your code and not be ashamed of publishing ugly code (or you won’t publish none). One probably has to learn this the hard way though :)
> Can you convince your boss that you should work one or two months in a problem and then throw away the result of your labour?
Well I can :D and you too should work for enlightened companies!
Thiago,
You seem to present an over-generalized view of what “the corporate world” means. Where I work we do have pretty high standards for code quality, and care a *lot* about how maintainable a product is.
Also, like Leonardo, I do believe it’d be feasible to propose this in cases where we have to understand the problem domain better. It would need discussion and analysis to get accepted, of course.
Tight schedules and short budgets do happen occasionally too, and these will certainly limit what’s feasible. I don’t think that’s specific to that “corporate world”, though. Schedules and budget is part of our society, and we have to learn to deal with them in a positive way.
Leonardo,
Yes, indeed if all one can do is writing ugly code, writing more often, publishing, contributing, and learning from mistakes and external advices are good ways to move forward. Reading and comprehending good code is also a good way to improve one’s practice.
But do you need to spend a month writing a prototype? Can’t you write several prototypes for tiny aspects (and of course, throw them away). IDEO does that with HARDWARE, btw. And maybe in agile/interactive development we can write prototypes on-the-fly…
Problem is, sometimes people write the prototype then go into ‘stovepipe/BBoM/Architectural Astronaut mode’.
Also, this: http://www.joelonsoftware.com/articles/fog0000000069.html
“The only way out this trap is acknowledging that simpler is harder”. I guess the key point is ABSTRACTION. If you get the abstraction / architecture right, there goes most of your problem. And yes, it is hard.
“If people knew how hard I worked to get my mastery, it wouldn’t seem so wonderful after all.”
– Michelangelo
Hmmm, so very, very, veeeerryyyy TRUE.
I find myself trying more and more to suppress my own OCD tendencies of perfectionism..
Hard to find the balance, but I really think this made a good point and more clear to me actually. :D
Pingback: links for 2009-05-03 « Object neo = neo Object