I definitely agree. As a student I'm well-aware that quality flies out of the window when a deadline looms closer, yet the work always comes out perfectly once enough power is thrown at it.

I've always compared learning to write good software to learning to play the guitar. You start out really badly, some good advice will get you going along very slowly, but given the standards (chords, scales, etc) and enough practice you'll be able to play loads of songs.

When learning the guitar I put the theory book down and started playing non-stop and now I play pretty well. I'm yet to be a 'good' programmer but given the practice I'll get there.

The definition of quality is missing. I know many people who have written a lot of source code, learned from mistakes, but still write crappy source code that triggers lots of bugs. The missing part is the urge to meet quality standards.

Quality standards vary a lot by purpose: Washing machines, satellites, hardware drivers, middleware, database GUI applications, reports etc.

An extremely good GUI programmer may not have the skills to write good enough quality for a satellite, and an extremely good satellite programmer may not have the skills to write good quality GUI applications.

Iterate, Repeatedly, Again and Again.

So "write terse code", "don't use comments" and now "don't waste time designing, just code"?

Has the engineering approach run it's course?
Are we harking back to the ways of old school hackers?

Or is it just Jeff?

Point taken of course. However, I do not agree that calling writing software as an 'engineering' activity is generous.

I think its fairly engineering like when you have to write software.

Come to think of it, back in college we had entire subjects around software 'engineering'.

Ah, the hacker mentality. Keep on trying until it works rather than spending some time to leaf through a manual and implementing a fix for the problem in less than five minutes.

It's not even true for pottery (all forms of pottery more complicated than the crudely decorated blobs of the early stone age were learned from others, not arrived at through trial and error) let alone for something more complicated like writing or developing software.

Just don't keep writing the same thing over and over again or you won't improve. There is limited learning in the array of possible mistakes you can make while writing an order entry system.

Learning from your own mistakes might allow you to achieve some form of "local maximum", but learning from others, from books, or just theorizing is necessary if you want to improve past your own "neighborhood".

This pretty much holds true for everything. I'm a photographer and every professional photog I know chants the mantra "you must shoot to get better".

I kind of assumed this article would talk about quantity vs. quality in terms of the number of shareware programs you create. I wrote one high-quality program in the past few years and have maintained it for a while, and barely make any money. I know a few other people who slam out one shitty program after another and make so much money that they live off of it and have plenty to spare.

Perfectionists have it hard...

I think the point is how get someone better at programming, it's not about the project themselves. Later designs performed by those programmers are made based on first-hand programming experience, previous mistakes and successes, not on theoretical assumptions.

For instance, a project analysis done by someone with little experience ought to focus too much on non-issues, while more serious but still expectable problems are completely forgotten. It's not about despising design, it's a critique of design done on theoretical assumptions. If there's not enough experience on the field available, prepare for incremental design instead of big-design-up-front.

> Has the engineering approach run it's course?
> Are we harking back to the ways of old school hackers?

In research engineering, you try lots of cheap things and see what works. If you already have software which does the job (production engineering), then you don't write new - though configuring and customising an existing product for a specific system may be a multi-year exercise for a large team.

Coding for pleasure or to learn, I'd agree that doing lots trumps theory - I learnt much more trying to write compilers that I did reading the theory.

It's not the same as not reading the manual - firstly, when learning, reading the manual doesn't ingrain the information, and secondly, when developing, there isn't a manual for the code you're writing. But if you're configuring an existing product or plugging into an API, then reading the manual is a very good idea - before you write a throw-away test case to find out whether the product does what the manual says. In my experience, most of the non-trivial fixes for things with have manuals are for things not mentioned in the manual, or where the manual is wrong.

After the learning/developing stage, there should still be a stage of refactoring to convert a prototype to a product, so it can be maintained if the original team gets hit by a bus, or can be put down and picked up a year later (it's been company policy most places I've worked that members of development teams travel to meetings in separate vehicles to prevent losing what's in their heads in event of accident, but once something gets productised the knowledge should have been documented, and the code refactored so any contractor can maintain it).

> Ah, the hacker mentality. Keep on trying until it works rather than
> spending some time to leaf through a manual and implementing a fix
> for the problem in less than five minutes.

Reading comprehension impaired, are we?

Fire and motion (Joel)?

One of the things my art teacher taught is to work in series. By the end of a series of twelve paintings of variations on the same scene I noticed a dramatic improvement. The first painting was crude and the last paintings were lively and interesting.

You will not know whether an idea is good until you try it. The shortcomings in an experiment will spark ideas for what to try next.

Programming is a tool as a pencil is a tool. Just as you can use a pencil to make either a shopping list or a fine drawing you can use write a program for a mundane purpose or in pursuit of higher objectives that may have some of the characteristics of "Art".

Hi Jeff,

I agree that trying more tends to bring out the best work. But when you don't have the luxury of time to work on everything, you got to pick and choose your battles. You can't fight on all fronts. You got to pick the battle with the best payoff.

I now agree with that, quantity lets you get better at quality. By quality I mean what ever metric you measure your project against?

My last job was very frustrating, I always had the feeling that they just wanted to push as much business out the door as possible. I never felt I had time to work on the quality of the software I was creating. Only after leaving and getting a break from that place was I able to see that the quality was actually improving. Over the course of the time I worked there crashes and pages to on-call folks went down. The quality improved because with every crash and error page that went out I did not just fix the issue at hand, I tried to fix the underlying problem and/or add in better error handling. It felt like all I was doing was putting bandaids on the problems (and sometimes that is all it was) but really I was making the quality better.

If I ever go back to that old job I would approach it with a much different viewpoint and I don't think I would have as much frustration.

That sounds like the advice Microsoft gave its developers when they wrote vista. "More is better" didn't work out to well for them, doubt it does for you either.

From a business perspective, that is the worst you can ever do. If you release a lot of bad applications you will get a reputation of developing bad applications, and you will not sell anything.

I agree that the fundamental idea of learning from your mistakes is a good thing, but I think it's more important to learn from other peoples mistakes.

You really can't make 1000 tons of crap anything more than 1000 tons of crap, you know. Quantity is one way to _learn_ quality, but it's not really quality in and of itself.

What you seem to be saying is that one needs lots of practise, and I can't argue with that. But that's practise, not production code. I've seen far too many totally ridiculous problems arise because people were more concerned with making many things than with making the right things, and not just in software. Sometimes, a little perfectionism can go a long way - a distance that would take far more time by trial and error.

@Thomas Winsnes : I don't think we're talking about releasing tons of software or even versions to the public.

Well, I guess this misunderstanding will go on and on in comments below ;-)

We could just sum up the storry with three words: "learning by doing".

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.

That being said, I think you're right, Jeff. Getting in there and doing it is the absolute best way to learn anything.

One fundamental issue with this approach is that it assumes the person in question has the intelligence to learn from the mistakes they make and the insight to see their issues and ways to improve things [and then put them into action].

No matter how many thousands of five-word sentences you write, if you never mix things up, step back for a couple minutes or expand your efforts a little, you're probably not going to get very far as a writer. Or maybe I should just put it this way instead: If you're not working with quality ultimately in mind, you're not going to hit it, no matter how large the quantity becomes.

Learn by doing, definitely, but 'quantity over quality' is a bit over-simplistic and somewhat a misnomer.

Great post Jeff, as usual. I think it can be summed up as:

Don't be scared to fail.

In my own experience, projects that get stuck in design because they have a lot riding on them, have a much poorer outcome generally, than projects that have less riding on them, and this can be started/restarted as necessary.

@Jan: Or should we call it: "Practices make perfect" ;)

Though, as a note to everyone including myself, please do those practices at home, don't do it with your production code.

The interesting part is, those ceramic course students won't be able to produce a better pot unless they notice what went wrong with their previous ones. Is it as easy to tell the bad code from the good one as we do with pots?

@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:

http://lifehacker.com/398068/ira-glass-on-getting-creative-work-done

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.

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.

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.

Sadly this is true. Quality is something you just rarely see anymore. very sad indeed.

JT
www.Ultimate-Anonymity.com

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 :)

Play this 1000x

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 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.

"Design" makes better software with current coder capability.
"Practice" makes better coders.

When you pull one factor responsible for success out and write about it, suddenly people miss the point and believe that what you are saying is that "This is the ONLY important factor in the success." I don't believe this is what you are saying, Jeff, not for a minute.

The point is that repetition is vital here. Larry Bird wasn't such a tremendous shooter, particularly from the foul line, because he only took foul shots - but he did shoot a lot of them... I've read stories of his focus and determination to be better at hitting those clutch free throws, and he was able to do it, in part, because he was committed to being the best.

Writing code is no different. I've written tens of thousands of lines of code over my career, probably hundreds of thousands of lines, and my success is due, in part, to the fact that I'm IN THE CODE on a regular basis. That is no different from being a concert pianist or a great tennis player. You have to DO IT to get better. When I'm not under a heavy timeline crunch, I'll challenge myself to take 30 minutes to an hour a day to learn something new and implement it in code. Beyond having an ever-increasing toolbox of solutions for those "yeah, I've done that before..." moments, it helps me be a better coder, helps me to strengthen those good practices and ultimately makes me competitive in the marketplace. If I fiddle-farted away my time doing the bare minimum, I suspect my quality and effectiveness would suffer.

Good post, Jeff.

YES.

The worst programmers I know have been people who only write code and are generally deeply unreflective, and in that context, I would agree with the critics who say that more doesn't equal better.

_However_, most of those programmers are lost causes anyway. Vastly more damaging are the huge amount of reasonably talented programmers I know who are so wildly hemmed in by the vast amount of decontextualized received wisdom and best practices and moralizing regarding programming they receive and believe that they become the equivalent of grammar nazis - people who nitpick tiny one-size fits-all context-free rules without ever really writing enough code to start learning the deep complexity of their own specific and particular domains. They're too afraid to of doing things wrong to ever learn how to do things right.

I think the craft observations are very apt. It's almost as though a lot of programmers are upset that they might be engaged in something involving craft and holistic right brain thinking. Richard Gabriel writes a lot about this (and especially the importance of reading lots of other really good code, which far too few programmers actually do). Maybe it's just the ironic nature of programming - our entire task in programming is to make knowledge hyper-explicit and executable, and yet, being humans, huge amounts of own productive capabilities have to come from that part of brain that can deal with amazingly deep patterns and structure non-verbally (you see this all the time with genius mathematicians who reason visually but then cover their tracks by translating back into the symbolic).

Looks like a lot of people missed the point here. The point is that good stuff can only be produced after a lot of practice.

There is no substitute for experience. That's all the point is.

It's odd that some people seem to think that quantity means "create lots of software" and quantity means "make software thats better by really thinking about it"

In this instance, it seems to me that the point is that (quantity of code)"iteratively writing software, release when complete" is better than (quality of code)"do the design, write the software, release".

Clearly the first way will create better software, simply because it allows the changing requirements of a client to be absorbed.

Im also surprised noone used the monkey analogy. Infinite numbers of monkeys would write the whole works of shakespeare in the time it takes one monkey to type the neccesary number of keys, but it took shakespeare a lifetime to do, probably because he had to really think about what he was doing.

Yeah sure, and 'working harder' *always* trumps 'working smarter'.

Man, things are relative and thus *most* of the time if you use 'always' in a proposition/decision/policy you make you are bound to be proven wrong.

The main thing that most developers lack is the ability to 'do a good job'. Obviously the definition of 'good job' depends largely on the context, but anyone knows a 'good job' when they see it.
Other times you have to work smarter, other times you have to work harder, the basic ability is to know when and how to compromise between the two and that comes from experience and sometimes it's a natural talent too.

But I have seen many a programmer that just don't get that and keep on following a set of ALWAYS and NEVER rules (some others just don't get programming in the first place, but that's another story).
"I always wrap everything with C++ classes!!! It improves the code!"
"I always write the most efficient code possible".
"I never write comments; comments need maintenance".
"I never use ASSERTs, they make you sloppy. I just make it right from the start".

=)) It's like I've been saying since I was about 16 : The road to becoming a good programmer is paved with bad scripts. ;;)

I do not have a problem with this mentality, so long as one's aware that you're responsible for your lack of quality. If it leads to problems, that's your fault, no one else's. If you can't fix it quickly enough, that's your fault. If it leads to someone's harm, either financially or physically, or what have you, then that's your fault.

A writer writes, a painter paints, and a programmer programs... but a writer does not write great novels by scribbling on napkins, and a painter doesn't sell his doodles in the margin of the daily paper. Likewise, a programmer does not become great by pumping out quantity code. A programmer becomes great through quality code.

So it's your choice, make a living, or strive to be great.

Does the same principle apply to blog content?

Read the paper "Unskilled and Unaware of It: How Difficulties in Recognizing One's Own
Incompetence Lead to Inflated Self-Assessments".

Practice only improves the product when the practitioner knows the difference between better and worse. Some people need outside feedback, with good and bad pointed out to them. Really. Read the paper, then reconsider your own incompetence. It's a useful exercise.

Also consider the insult, "He can write FORTRAN** in ten different languages". This is like someone else who mentioned 1 year of experience repeated 10 times over.

** FORTRAN is only representative of any language with weak or byzantice control structures, little or no data structuring, etc. FORTRAN IV had computed GOTO, line-number labels, implicit loops denoted by line-numbers, and other features now considered actively harmful to good coding. Substitute any other disparaged language.

Wow, this blog post is so bad that it should be criminal.

> When it comes to software, the same rule applies. If you aren't building, you aren't learning. Rather than agonizing over whether you're building the right thing, just build it. And if that one doesn't work, keep building until you get one that does.

I had a job once. It was a bad job; it was before I'd learned to be at all discriminating about the jobs I took. One day, I was gazing out of the window, into the middle distance, trying to work out some network protocol issue in my head. <Big Bossman> (you know the type: sales guy who made a startup with his docile techie buddy) happened to be passing and said, "You! What are you doing?!"; to which I replied, "I'm thinking, <Big Bossman>". His reply became a standard catchphrase in the office:

"You're a programmer! I don't pay you to think!"

Evolution is another analogue to pottery or software coding. Evolution requires a lot of begetting ( making lots of pottery or writing lots of code ) and requires selective pressures to push the begotten to be "better".

For pottery, the selective pressure might be your own satisfaction with the final artifact, comments by others, or the satisfaction of paying customers.

For software coding, the selective pressure may come from your own satisfaction with the code you wrote, software testers, bug reports from users, or competing products.

It's pretty plain here that the analogy it about making lots of iterations so you've got a good cycle happening. I'd also say the same logic also applies to project experience. Don't stay on just one project for more then 2 years - try a few different ones out rather then just theorizing over how to improve the one you're currently on. Whilst it is possible to improve some projects if the attitude is right from the managers perspective, sometimes it's a lot less stressful to just part ways amicably and find one which better adheres to your principals of whatever you think is good in development.

One thing the story doesn't say was whether the students were producing better stuff at the end or just a few random good pieces.

I think also putting pressure on the students also emphasizes making easy wins where possible. People remember what worked well from the last piece and what kind of aesthetics took far too long in terms of "bang for buck". Unless time is regarded as a finite resource, our approach will be skewed.

Okay, but only 'cause quantity leads to quality better than quality itself, you can't say something like "Quantity always trumps quality". It's somehow very, very wrong and to be honest it's kinda stupid too. It sounds like a bad advertising slogan to me.

But, now that i got that out of my system i totally agree with the contents of the post. The misleading title just bugged me really, really much.

I hope you aren't writing code for the Space Shuttle.
Or any major bank.
Or a hospital.
Or for a nuclear reactor control system.
Or for an air-traffic control system.
Or for the combat systems aboard a F22.

Etc.

Quality matters a lot, methinks. Maybe not if you are hacking together some marginal web app, but in a lot of places it is king, and needs to be.

I also think security = quality too. That's something else to think about here.

This example really has nothing to do with writing good code. As other comments have noted, you can't write a bunch of crap and get away with it. Where will all of this "bad" code go? That's right, straight to the client.

In software development we have a thing called code reviews. We have to learn and correct our mistakes before a final product is released. We don't write disposable code.

Some of you guys need to read up on the difference between skill and knowledge. I'll give you a hint, skill involves a lot of hard work.

Practice only makes perfect if you know enough to at least attempt to practice perfect technique. Trial and error is too inefficient a strategy to discovery perfect technique. Progression from beginner to journeyman to master requires study of master material and/or master mentoring. I think it takes at least 10 years to get really good at anything significant. And much longer to become truly exceptional. And that's with the benefit of master role models to follow.

I think this is a complete load of rubbish. You are massively over generalising if i only know a few basic approaches to a solve a problem no matter how many times I attempt to solve the problem I am going to do it in a similar way, I will only reach the best within my current skill set improving only slightly each time. If I learn new techniques by reading, theorizing or learning from others I am going to improve in other ways, usually that apply more generally to all programming not just the current problem.

You can't simply say quantity is better than quality or vice versa it is as with most things a balance.

You have also picked a quote from a ceramics class that implies it is a beginners class. Of course quantity is important at first in programming we all remember our first hello world, loops, methods, classes and recursion programs. But then to improve my programming ability past these basic constructs I have to do the quality side learning about advanced features that are often language specific.

All well and good, as long as some PHB isn't there to scream "ship it!" before you've worked through all the poor quality code/pottery and started producing the good stuff. And that you don't have to cope with the problem of disposing of 1000 tonnes of second-rate crockery :-)

As others have said, "practice makes perfect", "don't be afraid to fail". I'd add the story of the Buddhist archer who smiles each time he misses the target, because he knows he's one shot closer to making the bullseye.

The pottery story is persuasive, but proves nothing.

You can disprove an assertion with a single counter-example, but you can't prove a positive assertion with a single analogous example.

The crucial lesson here is to test, experiment, push the boundaries and most importantly,learn from mistakes. That doesn't necessarily follow directly from raw quantity. By selecting for quantity, you're applying no pressure to improve, even though it might occur as a by-product, in those students who were already primed to strive for perfection in their work. This merely demonstrates that some students had implicitly learned the lesson before they had even walked in the door, and they were being used to give a lesson to the other students. In a group of students that were purely looking for the best grade, there might have been a different result.

In other word, suck and see.

Actually this is partly what I do.

>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.

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...

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.

Jeff,
just wondering if you left out a few key paragraphs there in order to get the reaction above?

I'm a little disappointed with the quality of the posts lately and therefore am doubtfull if quality comes with quantity.

That's why I love this blog...
:)
Completely agree.

bullshit. I know a lot of developers in big projects who never see their errors alive, and have no learning curve from writting their crap.

Damn this is a good post. I disagree with 70% of what I read in this blog but the good stuff is so good.

Of course this post doesn't apply to code-monkeys who only use two functions out of their IDE - copy and paste. But for people like us, who read around the topic in an attempt to learn, this is a good lesson. Sometimes it's better to do something, even if it's wrong so you can get it right next time. As Brooks said, plan to throw one away, you will anyhow.

Is 10 people with 1 year of experience really equal to 10 years of experience? To take this a little further, I am sure those monkeys will write Shakespeare. There just needs to be more of them.

--TomS

@matthijs
"It's not even true for pottery (all forms of pottery more complicated than the crudely decorated blobs of the early stone age were learned from others, not arrived at through trial and error)"
This comment is blatantly not thought through, because in order for it to be learnt from others, *the others* must have used trial and error. At the end of the day, the only way to do something better is to do lots of things and see what works best. You can use other people's ideas to guide your work, but remember, at some point, they just DID it and checked to see what happened.

And for those saying "This just means you'll release buggy code", face it, you'll release buggy code ANYWAY.
Frankly, I'd rather have code that someone had thought about for an afternoon, coded in a week and tested for a month; than code someone had thought about for a month, coded in a week, and tested in an afternoon.
They'll both be buggy, the difference is the code which has been tested will have removed the bugs that annoyed the user, the code that had been thought about will have removed the bugs that annoyed the designer. I'll take a messy algorithm in the middle of a calculation and a chunk of code where the presentation's tied to the business logic, over a button that crashes the program when you click on it.

"let alone for something more complicated like writing or developing software."
This merely shows you've never tried to make a mug in a pottery class.

classic hacker 101:
repeat a very basic sumb thing for some time to acquire or perfect a skill

applied to programming it could be renaming/refactoring some classes by hand instead of using the IDE feature that do that for you, or use your compiler only on the command-line instead of using the GUI, etc.

morality:
a dumb repetitive task can teach you a lot about the things you take for granted

"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."

Actually, that sounds like a great programming game for a CS class. And I'm not sure what the result would be.

But I'd argue that Group A would probably say "Why make them work together?" There's not much reason to link a program that calculates square roots of polynomials to a program that calculates your tax return. There's even less to link it to a second program that calculates square roots of polynomials.

With one caveat, I would say this is completely true. Assuming that the creator in question is trying to learn from the project, quantity will trump quality any time. Another way to put it is practice makes perfect. However, one must remember that practice involves an attempt to make oneself better. If someone is just churning out crap, all they'll end up with is crap. However, if you're learning from your mistakes, the sooner you make them (ie: the more you put out) the sooner you'll learn. The example given holds because it was an art class and the students were there to learn. If they were just there to get a grade, it's easy to shovel clay onto a platter and then straight into an oven...

This is also why hobby programmers are nearly always better than people who just do their programming at work. In a work situation it's fairly imperative to write quality work, so there is extra pressure to worry about that. However, when you're just following a hobby, the joy comes from the time that you spend doing it, not really the perfection of the end result. If you're free to make mistakes (and learn from them) then you'll see a LOT more of the fruits of your labour. You can argue that some people have/make more time for it and give up other things, but that's the same in any aspect of life. That's also part of it being a hobby.

I'm also against theorizing too much. If you look what you learn when you study computer science, it's way too much theory. Can spend days on trying to find the perfect database layout, the perfect UML description for your code, the perfect use case scenario. In the same time other people are doing that, I have already written the full product. Okay, it may not have the perfect database layout, there may be no single UML diagram about the structure and I just took whatever use case came to my mind, but the product is there and it works. As the product is not dead, there is still time on documenting and improving it; but wasting too much time upfront is always a bad idea.

Not theories win, code wins.

Quantity is not evrything.
Look at this post, and at the three you have linked.
Those previous post were more informative, more interesting.

Your recent post are less interesting IMO.
You can make loads of shitty burger at Mac Donald, you won't improve and become a chef.

The idea of generating lots of ideas for Interaction Design / User Interface works. Build lots of mock-ups, plan to throw away most of them, and iterate until you move towards a great solution.

But in terms of software engineering, I'm surprised to hear this, and it seems I'm not the only one?

Jeff,

I have heard it said that half-truths are more dangerous than lies. There is certainly a grain of truth in what you have said, but there is also much that is misleading:

The true:

You can't learn programming unless you program.

The false:

1) "Stop Theorizing"

Are you suggesting that you have to make a choice between thinking and doing? Perhaps you should think about douing "both". After all, isn't theorizing exactly what programmers *do*. Ultimately, a program is always a model of something - someone's business process or whatever - in other words, a theory. Moreover, isn't "Stop Theorizing" actually part of the Atwood theory of programming?

2) "Quantity always trumps quality"

No, it doesn't. If you keep on making the same old mistakes you just get really good at making them. "Practice makes perfect" is a myth. "Practice makes permanent" is closer to the mark. You do have to keep practicing - but you also need to reflect on your practice, to learn about what good architecture etc. and *why* it is good. In my book, "Quantity + Quality" trumps quantity alone.

In our branch, we have 11 programmers with 1 - 4 years experience and a systems engineer with 12 years experience. When the 11 programmers can't figure one thing out, finally they go to the engineer. Those 11 programmers actually don't get so frustrated when their accumulative thoughts can't nail a bug down, because they have the engineer.

Quantity or Quality?
- I will say: it depends.

>Quantity always trumps quality

counter-example: this blog.

Sorry, could not resist :-)

>>Quantity always trumps quality.

Worst. Advice. Ever.

Read the Mythical Man-Month.

And "not theorizing" means you're a crap software engineer. Sorry.

Shitty programmers don't look at their code from the point of view of someone who has proven algorithms and can demonstrate in theory that an algorithm will always work (even if they only prove it in their head). This is the #1 cause of shitty code - not thinking things through, and handling edge cases.

Jeff, I *hate* this idea.

I also know from observation and experience that you're right.

It's as counter-intuitive as the wisdom of crowds, and somewhat analogous, except that self-correction is done not by multiple individuals, but by a single individual doing multiple iterations.

That said, I still loathe PHP.

PHP is probably one of the most successful (i.e. ubiquitous) languages on the planet.

I'm going back to bed.

Practice helps. Theory helps.
The best quality and quantity results are achieved when you balance practice and theory.

if you write a lot of poor code, you will keep writing a lot of poor code. At best you will be able to do it faster.

If you try to make every program better then the last one, then you see improvement in your quality. Like any other activity, you need to practice, but practicing bad habits, just reinforces them.

The Potter tries to make each pot better then the last one. The musician tries to improve with every performance. The programmer needs to make each piece of code better then the last one.

There's an ancient military saying, "Quantity has a quality all it's own." It doesn't matter how highly trained your 5,000 men are, if the enemy has 500,000 you're going to get beaten.

While there seems to be a lot of people that disagree with your approach, I've found that it suits me quite well. Brute force coding, while not the most elegant thing in the world, does work, but only if the programmer has the desire to make their code better. I tend to write code at least 3 times myself. First time to get it working, second to work out any kinks, and then a third time to clean everything up and improve upon anything that may require some optimisation. The end result is that each new evolution of the code produces something that you can see working in a short amount of time, that can be improved upon.

I will have to admit though, if you're writing code for something that could potentially get people killed if things go wrong, it's probably not the best approach.

Sorry, I disagree with this blog.

Bottom Line: Do it correctly the first time, everytime.

Perfection is impossible to attain. Define expectations. Set a deadline to create urgency. Evaluate progress on a reliable timeline. Once expections are met, go live. If that means the deadline slides, then that's what happens. But part of that decision is knowing what something is good enough and what the cost will be to make bug fixes.

The problem is that if you're going for quality-out-of-quantity, you may just end up with a pile of half-built pots, abandoned halfway through when you realized a problem and started over again.

This happens *all the time* in open source and hobby software, if there is no demand to ever "ship" anything (sell a finished product).

If I look at your recent posts about software development and their comments, I can finally understand, why there is so much bad software.

Sorry to say it (again), but your posts are not helping. You just encourage bad practises. Really bad practises. Maybe you try to bring people to think about what they do by posting highly questionable advices, but I think this doesn't work well (in general).

Interestingly, your blog is like a car accident. I try not to look at it, but somehow I keep coming back only to find myself more horrified.

And...

Brute force coding isn't sexy. 100% honest, it is a waste of time and resources. If you require this to launch a live app, you will be behind before you know it. If you are hoping to work for a good shop, you better find a way to up your output.

In today's software world, being flexible and being able to react quickly is the difference between the guys struggling to keep their head above water and those that are climbing aboard a yacht. No one wants to pay for more fingers on keyboards. Companies will go to India for that. Companies want business developers that can attain some vision AND have quality code.

Code monkeys are an off shore profession now. Brute force is for India and hobbists. Take pride in your craft.

Notice that the story only said "the works of highest quality were all
produced by the group being graded for quantity". It did not say that
all students in the quantity group performed better. The students who
did best probably were gifted students who really cared about the
results of their efforts.

You need to care about your work. You need to reflect about the results
of your efforts. You need to really want to improve.

After that, it's really a matter of effort.

It's the analogy that's probably causing the most confusion here.

These "potters" working towards quantity are producing identical copies of one item and therefore the quality will naturally come.

This therefore translates to coding in that if you have a program to write, you should keep re-writing it as many times as you can in the same timescale it takes the "quality" person to produce theirs. This is where you may end up with the same result at the end in the same timescale.

What it should NEVER entail is producing 50 different pieces of software of which 49 then turn into maintenance nightmares.

Picture this in a building trade. You spend some time and build one house that is well built and will last a long time. Or, you build, knock down, build, knock down, over and over again until you have the one house you're happy with. Or, you build 50 houses, getting better as you go along, just make sure you're the person buying the last one and not one of the first!

At the end of the day, its a good discussion point but should nevert be considered a black / white best practice guide. I for one work on the quality of software although I may take many interations on one piece to achieve that quality. There is nothing more satisfying than when a mature product starts coming into its own because the time was spent in the beginning getting things right!

Robin

Hey guys...I have studied Quality methods for years.
Designed Q.C. methods for both Ford and Mazda. U.S. and Japan.
In my own seasoned opinion this article is very bad advice.
Quality should be used before, during and after.
PDCA: Plan, Do, Check and Action.

I would agree with the point that there's no substitute for hands-on experience.

However, I have to say that the analogy is not so hot in this case. The students in question made objects with the exact same "requirements" over and over and over. It would be great if we could do that.

However, in our business no two projects ever have the same requirements. So there's really no way to ever get the kind of experience programming that the ceramics students got in even one semester.

http://www.infoq.com/news/2008/08/programming-processes

Like most generalizations, you can find situations where this does not apply and where it does.

This advice works for those of us who are perfectionists, who have this desire to do it right the first time, to do it the most efficient way the first time to the point where endless debates will occur and nothing happens.

Planning needs to happen. Design needs to happen. Yet some of us will think the planning and design is an end instead of the means.

Like most things in life, it is a matter of balance. This advice works for those of us who are out of balance on ever finding that "perfect" plan or design.

Sounds like agile to me.

> Quality should be used before, during and after.
> PDCA: Plan, Do, Check and Action.

In fairness though, isn't continual process improvement also part of any good quality process? One could make the argument that this is what the students were doing by making pots over and over.

One good point here is that for these students its no real problem to just chuck the pots that suck. I understand the same goes for photographers too. Supposedly the difference between an ameteur and a professional photographer is the *amount* of pictures that are taken. Pros take 10 or 100x more pictures than I would. We just never see the ones that suck.

Software developers don't really have that luxury. What we *can* do is try to use iterative processes, and not be afraid of refactoring large swaths of badly done code.

Be Joel, Be Jeff, do HR posts, ad nauseam, blog for people who fear coding

... provided you work with the sort that will actually learn from their mistakes and not assume that everything they do is without reproach. I've peer reviewed several personnel who are so insecure about their work that they see constructive criticism as an attack on their intellectual property.

The statement "Quantity always trumps quality." and then the example of blogging is misleading in trying to prove the point that developing a software application is the same.

Quantity of crappy code will not in of itself produce quality code.

I always enjoy this quote from Stalin, "Quantity has a quality all its own."

Couldn't disagree more with you on this Jeff. This type of thinking is what leads to outsourced jobs, poor quality software that never lives up to its hype, and tons of bug-basher jobs that don't provide any challenges to the solid devs out there.

Anyone who believes quantity trumps qualty is doing all devs out there a disservice by perpetuating the "code monkey" reputation that we have been trying to get away from for years.

For one thing that's a crappy analogy lacking clarity. If (as it appears) the class was given a single grade applied equally to each group for their respective work (either weight or quality) then of course it is possible (on either side) that the group was a) pulled down by a crappy individual(s) or b) excelled because of a very talented, intelligent individual(s). You can't really come to a definitive conclusion based on one test result.

Additionally, individuals do not learn equally, and different experiences teach different lessons. Joe X may glean more knowledge from his mistakes than Bill X. Some programmers who have programmed for 20 years still put out crap code while others who have only programmed for 3-5 have polished, efficient code.

There are no absolutes.

I agree that one must code to become a better coder. Just as one must swing a bat to hit a baseball. But there needs to be principals, coaching, guidance, etc.

"The best people in any field are those who devote the most hours to what the researchers call "deliberate practice."
It's activity that's explicitly intended to improve performance,
that reaches for objectives just beyond one's level of competence,
provides feedback on results and <b>involves high levels of repetition.</b>"

http://money.cnn.com/magazines/fortune/fortune_archive/2006/10/30/8391794/index.htm?

Also, I now expect 3-4 posts a day from you, Jeff, because quantity is more important than quality, don't you think?

I mean, really, don't spend time on things like structure and grammar. Just churn 'em out, ok.

It's not about churning out factory replicas of the same bad design like some automaton. It's about constantly improving by doing. When you are doing you are learning and when you are learning you are improving. And then when you're done you start again but a little better than before. Just like exercise, every time you do it you have to up the difficulty just a notch if you ever want to see results. That's the only way to grow big and strong. Arnold didn't get to be the President of the People's Republic of California because he kept lifting little rocks; he started picking up progressively bigger rocks until he could destroy the snake god-king. Bill Gates didn't grow Microsoft to be the great and terrible entity that it is now by just gobbling up one competitor; he had to keep feeding that beast until he had the software behemoth that is loved and hated the world over! We need to do that too, nobody learned to how to be a programmer from just thinking about the greatest "Hello, World!" application. They coded a terrible one then they created a slightly less terrible one, then they added something that was cool and kept going and improving. They added and added until that little "Hello, World!" became Vista (err, wait...).

Anyway, the point is to keep challenging yourself by doing; not just thinking about it.

Well this shows that you learn through practice.

But does this mean that once you have learned, that you can still produce the best results quickly?

Mostly likely not.

This post is dead on target. I am curious about those who are so vehemently opposed to it. Have they no way to improve other than to study the works of others? Do they not realize, perhaps, that they are improving by evolving the techniques and understandings they used in earlier work?

Having crapped out hundreds of little apps of questionable quality, I can appreciate what Jeff is getting at with this post. You only really learn from your mistakes and you can improve your programming skills much faster by completing things and moving on to the next project as opposed to slogging away at a giant project until it's perfect.

I think a good analogy lies in video games where you may struggle at the first level in the beginning, but after a few tries, you can breeze past that part and be challenged by more difficult levels.

In the case of programming, it is the basics that you master after many tries which free your mind to tackle problems of ever-increasing difficulty.

What's fun about getting 100+ comments is that you get every opinion represented, multiple times.

I'm here to represent the "what's the deal with all the other commenters misrepresenting your post?"

I've figured it out: those who disagree with your post just read the title and immediately skipped down to comment. They couldn't have actually read the article. That's all I can come up with.

Maybe you should have changed the article's title to "read the article guys, I assure you this is a good one", then you'd get different comments.

"Quantity of crappy code will not in of itself produce quality code." I have to agree, one of my ex coworkers wrote a lot of code, and I mean a lot, but it was all the same crap with the same mistakes (he is a vb.net guy, and all his code was fill with global variables in modules, reference parameters instead of creating a class, etc.), he was a good guy and in his mind he was an excellent programmer, helping the company writing lots of code, but he never care about the quality of the code, several times I tried to talk with him, I even give him my code complete copy, but that didn't matter, he didn't want to change.
Now he is gone and I have to maintain his crap, and let me tell you, his old crap is as wrong as his new crap, the only thing he learned here was the Framework 3.5, but his style of programing is still VB6.
In the end the only thing that matters is you, if you care about your craft you will put love in it and you will evolve, there is no formula, it's not about time, it's no trial and error, it's not about how smart you are, either you found your passion and you are coding because you love it and trying to improve every time, or you doing it to pay the bills and don't care.

This theory doesn't appear to be working for Linux. Maybe with a hundred more versions they'll turn out some quality.

I have to agree with the main sentiment here. Writing lots of code does not automatically make you better.

Practice doesn't make perfect. Perfect practice makes perfect.

Repeating the same mistakes over and over just ingrains them.

It's truly shocking how many of you missed the point of this post entirely. Not even an air ball miss, either. You guys are punting the balls in opposite direction of the basket.

Makes me kind of miss the '05 days when you'd get 8 or 9 intelligent comments instead of a massive stampede of folks committed to disproving a point they obviously didn't understand in the first place.

Ask Nintendo how the Quality over Quantity worked out for them... I think they just said that because third-parties didn't want to touch their system back in the N64 days due to the lower installed base and higher price of creating cartridges as opposed to CDs.

Just thought I'd mention that since any point I was going to make about the post itself has already been made. Though since the idea of the post is Quantity over Quality, maybe I still should say something...

Where to begin.. Do programmers improve over time by sheer volume of code written? Maybe.. but it depends on whether those programmers pushed themselves to produce better code, and that requires the drive to improve. Quantity can help produce quality but quantity alone does not trump quality.

Interesting analogy with the pots. One difference: it's a lot easier to recognize a good pot than good software.

With pots, you could probably learn by trial-and-error ONLY and get decent results.

With programming, learning good principles from smarter people is crucial.

Interesting. I like it. There is an organizational research theory called “Action Research” which this sounds very similar to.

I’m not sure I like the analogy compared against using potters. It is a dangerous comparison to draw.

The danger is that in the real world, management would see the first pot from the quantity group and say, “wow you made it in 5 minutes? Great job... now go and make a teapot”.

Regards,
Patrick.

I agree that writing lots of code will increase the quality of your code. I agree with one serious caveat, a very serious caveat. That only works if you're the kind of person who is interested in increasing the quality of your work. Well, duh, isn't that obvious and isn't everyone interested the quality of their work, you say.

I'm convinced that the vast majority of programmers aren't interested in quality, unless they've been given standards, and incentives to produce quality code. And, there many programmers who will just produce lots of bad code. As a former manager of a team of 14 programmers, I can attest to that. Of those 14 programmers, I never had more than four (at a time) that wanted .. needed to produce good, bug free code. They were the same folks that would read programming blogs like this or books like McConnells.

Let's face it, Jeff's preaching to the choir for the most part. Most, if not all, folks reading this blog are interested in improving their skills.

I appreciate the theme, but you come across as having divided the world into "analysis paralysis" and "just start typing". There is a better middle ground.

You have to read a little into the story to get the necessary preconditions:

1. These are all art students, so they're highly motivated to do well, even if their grades don't depend on it.
2. They're in an art class, so they are being exposed to information, techniques and feedback that will allow them to improve.

Trying to extrapolate to other situations without these preconditions might lead to different results. The person who does the same thing over and over is missing one or both of these vital qualities.

I think if you're motivated, and you seek out the tools to improve yourself, this is a good formula for success.

If this were universally true, then the older, "more-experienced" developers in my shop would always write higher-quality code than the interns who just graduated from college because they have more lines-of-code, more designs, more apps behind them. But I'm sure everyone can point to a 30-year "veteran" in their shop that just writes horrific stuff.

No matter how long you do something, you don't get better at it unless at least two things are true: 1) You're exposed to feedback and critique from colleagues, teachers, books, magazines, etc. 2) You're open to the idea that your skills have room for improvement.

Some people "get" programming from day 1, others will work their whole career remain clueless.

Just thought of something interesting:

Go ask the Spartans if quantity is more important than quality!

(Well, you can't really go ask them, but I think you get the point.)

Seriously, though, it's like politics. If you go too far in either direction, bad things tend to happen.

Just like the comment you made a few weeks ago, which you removed from your post without noting it, by the way ("It's OK to end up with comments in your code, but never, ever start with comments"), your statement here that "quantity always trumps quality" is yet another dogmatic generalization which is dangerous in that it may appear like good advice on the surface, but gives way rather quickly under examination by those that know better.

Someone alluded to "Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments" - I also encourage you and others to read it and remember that it is applicable to everyone, there are some great insights within that

One of my favorite quotes, for numerous reasons, is this:

"It takes considerable knowledge just to realize the extent of your own ignorance." -Thomas Sowell

That sums up the findings of the previously-alluded-to paper. While trial and error will teach you a few things, using "if that one doesn't work, keep building until you get one that does" as a metric alone will do little to educate you.

This issue is more complex than your simple post lets on, and for those too ignorant to know better, your statements may give them a false sense that by simply writing more code they will get better - it just isn't that simple. Maybe for ceramics it is, but not for writing software.

Jeff,
I can't really agree with this post. I've worked with some devs who turned out tons of code and it was almost all a unmaintainable kludge that needed to be rewritten and added nothing but technical debt.
Also, to claim that quantity always trumps quality just doesn't add up. Think of all the Friday the 13th and Nightmare on Elm Street films that have been created, they haven't really taught the responsible filmakers how to make better films they just keep slinging crap out the door.
The most important attribute of a solid software developer is someone who values quality over quantity and understands good software design pratices in terms of maintainablity,security and performance.

Mr. Bunting, although I agree that a rational person should have a good idea of how ignorant they are (Secrets of the Rock Star Programmers: Riding the IT Crest). The only way one can accurately measure ones ignorance is by 'trying'. If you try and succeed, you probably aren't as ignorant in that area as you might have thought. If you try and fail, then consider what you did wrong and do it again. Thereby overcoming your ignorance. If you don't try at all then you remain ignorant of your true level of ignorance, which is a worse situation. Learning is the replacement of ignorance with understanding.

Mr. Peaslee, this post isn't really preaching to the choir. Allot of people who read these blogs (IMHO) already think they have done something worthwhile by merely reading. They haven't done anything except give Mr . McConnell a few click-thoughs if even that. Without action we're just navel-gazing.

Thanks.

You know, I really wish that when I was first starting out in programming, someone would have pointed this out to me.

I continued to press on and code my heart out, trying out new concepts all the time and trying to push myself, but when something wouldn't work out, or I would look back at code I did that wasn't any good, I would get pretty frustrated.

This concept says that the learning is in the coding, though, and I really like that. Through the years I can certainly see how my code has been "chiseled away at", so to speak. Those problems that I've tackled once, solved, and then rehashed again in the future using better logic or more elegant code were making me into a better programmer, not only "fixing old mistakes". Thanks for the post! :)

So who has to maintain the other 49 pounds crappy pots that are made to get the 1 good pot?

Good luck with that strategy.

I think it's important to point out that the quantity approach only works when you actually use quantity as a means to improve quality. Writing one to throw away is no use if you write the exact same thing the next time, and the next time after, and the next time after...

Experimenting, failing and learning from your mistakes I'm all for, but doing the same mistakes over and over again is usually just a waste of time.

As other people have mentioned, balance is the key (as always).

I think you are totally correct. I see the phenomenon of over-theorizing in so many walks of life. For me I see it in programming and in music.

I don't think you're saying it isn't good to plan things out or it isn't good to use established techniques (in other words you would not advocate writing spaghetti code with GOTO's everywhere),

what you are saying is that some people over theorize and indulge in a certain kind of neurotic inhibition: OMG IS MY DESIGN ABSOLUTELY PERFECT? Before they even begin writing code.

Better to come up with a good design, and not worry whether it is absolutely perfect, and then go ahead and code it. Then you learn from your mistakes.

In the words of G.K. Chesterton, "If a thing is worth doing, it is worth doing badly." I think he meant to say if you are inhibited by over perfectionism or in this case over-theorizing, you really need to just jump in and do the best you can. You'll learn from your mistakes.

Regards,
-Derek Andrews

p.s. I notice a lot of this design neurosis in music also. People talk endlessly about harmony and theory and spend too little time trying things out. It isn't that learning harmony and theory is wrong, it is just that getting too neurotic and perfectionist about it will stop you from learning as easily.

The phenomenon of excessive theorizing is strange in itself. For all the books and theory published since 1993 (as an example), very little has been added to the pool of theoretical knowledge. You can cover a lot of ground (still!) with books by Stroustrup and K&R at the conceptual level (just two books). Design Patterns is a great book, but poorly written. So we are now at three books of theory. If you repeat this process, you may find another 3 books to satisfy your tastes.

Books such as "Learn to Space Travel in 21 days" do not count. You are better off experimenting that following a narrow-minded book for 21 days (or chapters).

Six books. Big reading list :)

Daily, I see a huge difference between people who can execute on their ideas and people who just spin their wheels and whiteboard endlessly. If you have a grasp of some basic theory, you can produce great code in 2-3 iterations. More than 3 iterations would be an indication that chosen approach is not the best. It may not be wrong altogether but there is a better one out there :)

What I would say is: take about 80% of the time you would spend on process and theory and spend it actually thinking about the code you are writing. Sitting there, with your editor open, executing each line in your head. Execute all conditions for your conditional statements in your head before you actually code them.

If you don't do that, why bother with the other stuff?

Of course, this goes for everybody in the organization. If testers don't search the bug db for existing bugs before filing new ones, what's the point in testing? If product managers don't talk to customers before proposing features, what's the point in working on the product at all?

"Craft" is probably the best definition, although it does smack of little old ladies weaving wicker baskets...sometimes software development can raise itself to the level of art, no?

“After a certain level of technological skill is achieved, science and art tend to coalesce in aesthetic plasticity and form. The greater scientists are artists as well.” (Einstein)

When I was growing up, my parents would say "practice makes perfect". I have been programming for 20 years. A few years back, I wrote a TFTP client for the first time. I was to write it a few more times in quick succession for my project. The first one, in Java, was junk. I wrote it again in Java and it was better. I then wrote it in C for Linux, and the code was starting to get quite slick. I then wrote it for MS-DOS in C and it was rock solid cool and done quickly. My parents were right: practice did make (well, mostly) perfect.

@ o.s.
I don't think you're on the same wavelength as Jeff. (Or perhaps I'm not). I see it as condoning writing software to do the *same* thing again and again. Like when you practice a piece of music, you play it (or sing it) again and again. If you're just writing software that does different things, the skills may not transfer.

> Go ask the Spartans if quantity is more important than quality!

I was thinking along the same lines, but with Zulus and Brits at Rorke's Drift.

However, I suspect a Zulu would want to direct your attention to the Battle of Isandlwana. So don't get overconfident. :-)

Funny, for all the drivers on the road, with all the practice they get, how come they're not all Formula 1 capable? Practice is more than just doing. It's a concentrated effort to improve. That's why 1 day at an advanced driving school will teach you to be a better driver than 10 years of daily commuting.

Jeff doesn't create posts that you might want to agree with. He style of writing creates many back and forth comments that don't add much, but give a perception of active debate. PHP sucks, don't comment, write terse code, xml sucks, #regions suck, everything sucks. Coding Horror indeed.

@Carleton
I see your point but the most important goal really isn't the repetition(quantity) of the code you write. Its really most important to understand how to design good code and tools(quality) and not so much details about any specific tools or code you wrote. Thats what will help the most since the actual technology,code and tools will constantly change.
For those who still don't know software development is 100% design not engineering:
http://user.it.uu.se/~carle/softcraft/notes/Reeve_SourceCodeIsTheDesign

Pottery isn't reusable in the sense of physically incorporating your previous artifact into the next one. A lot of artists are faced with the prospect of mastering the skill of creating something from scratch. Your analogy is perfectly fine if you feel the same way about your software.

@ o.s.
I agree with you in the macro sense (e.g. if I'm working on a team feature in my job over the development cycle of that feature). In the micro sense, I think Jeff was trying to focus on the specific issue of quantity being better because, at first read, it is counter intuitive and makes for good conversation. But it makes sense if you think of it as practice (like practicing the piano). In that micro sense, I agree with Jeff.

http://pastorgeek.blogspot.com/2008/08/no-no-and-thrice-no.html

[...]"Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity."

Assume, we can apply the 90:10 rule here: That makes 90% crap as result of the "quantity group" and 10% high quality, while the other group may have produced 90% "good quality" and 10% crap.

If you ask me, I'd rather see 90% of all software being good quality than 90% being crap.

learn something about function points, time complexity, and mccabe complexity... writing lots of code without thinking is stupid... writing lots of code to get good at coding, without thinking, is also stupid... writing lots of well thought of code, while keeping in mind to minimize time complexity of your algorithm and overall mccabe complexity of your code, is *the* right approach.

I agree completely. I remember when I first wanted to write a program, it must have been about 1982 or there about and I must have been about six at the time. My Microbee computer could boot to Basic, so I thougth "why not write a program?" But my dad explained to me that it didn't work like that, and you had to learn the language first.

Being a six year old I didn't listen. I opened the book to the the "Hello World" example, then started playing. I learnt what I needed to when I needed to. I didn't learn the things the book wanted me to know, and I did learn things not in the book.

And that's the way I have learnt ever since.

I have found writting lots of code normally leads to smaller code base, because it normally means lots of versions/options, of which only the best is retained, rather than lots of redundant or lengthy code included in the final version.

Anyway - well said.

I strongly disagree with the idea of this "Trial & Error" philosophy of software development.

I believe this philosophy is put forward by developers who really enjoy writing code and probably are very good at it. They love writing code so much that they want to get started as soon as possible. Premature coding always end up with a disaster. So what does this group of Alpha Programmer do, they "learn from their mistake in programming" and try again. What they fail to realize is that the project was doomed even before the start of coding.

So my theory is, put time in design. A phrase use by Army comes to my mind that says it all:
"Time spent in reconnaissance is seldom wasted".

"Quantity always trumps quality"

This is a false contrast. You suggested that quantity produces quality, which is true, but a pile of crap, no matter how big, is never going to be better than a nugget of gold. (Unless you're in the fertilizer business I suppose).

I agree that trying more tends to bring out the best work. But when you don't have the luxury of time to work on everything, you got to pick and choose your battles.

I didn't learn the things the book wanted me to know, and I did learn things not in the book.

I'd like to repeat what No-Name Timmy said.

@Farrukh The programmers I would could Alpha programmers, tend to see their mistakes and what to learn from them, before us mere mortals would even notice something wrong. Perhaps, its because they are used to see 20 steps ahead while we only see 3? They also tend to get stuff out quicker than us.

Then there are those that fancy themselves Alpha programmers. They are the ones that doom the project.

And to be fair. I learned programming initially from trial and error in QBASIC back in the dos days. Had I taken to needing to learn everything before hand I would of never have started programming. Even now days, when I see new technology I just get stuck in with it, using trial and error to learn about it. Of course, this trial and error occurs in my own time, not on my work time. But it gives me knew knowledge to bring back into work.

Trial and Error works to learn. It also does make you better at using the tools. But you do have to seek information else where to point you in even better ways that you had never considered.

"Funny, for all the drivers on the road, with all the practice they get, how come they're not all Formula 1 capable? Practice is more than just doing. It's a concentrated effort to improve. That's why 1 day at an advanced driving school will teach you to be a better driver than 10 years of daily commuting."
Rubbish. First thing I was taught on an advanced driving course was that it's all about continual improvement, and that if I treated it as a single day course of improvement, it'd have no noticeable effect other than to make me more arrogant.
In other words, it's about continually trying to improve, not just doing a surge of research.

"Someone alluded to "Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessments" - I also encourage you and others to read it and remember that it is applicable to everyone, there are some great insights within that"

Wow, so apparently judging your own work is really difficult to do accurately. Maybe you should get some external examination going on.
Wouldn't it be handy if you had a large battery of work that they could look at and compare, rather than a single piece of work that you didn't want to show them while you were still trying to get just right?
Hang on...

From Rob:
"So who has to maintain the other 49 pounds crappy pots that are made to get the 1 good pot?"

I LOVE that statement, in a masochistic, "taste for suffering" connotation!

Just thought Jeff might like to know, I've started a blog, and this entry is referenced in my third entry. See http://blog.dare2xl.com/ (which actually redirects elsewhere but the destination may change later).

As the story goes: "the works of highest quality were all produced by the group being graded for quantity".

Assuming no subjective elements here (which is pretty difficult for ceramics), that does not mean that the quantity group produced better quality ON AVERAGE. Rather it means that the law of averages applies here as it applies everywhere; given a large body of students with roughly the same skills and instruction, producing more things offers a better chance of producing great things.

But what about all of the not-so-great things they produced? How good were they compared to the "quality" group? We're not told, at least not in this out-of-context quotation. Was the bulk of the "quantity" group good enough to show in an art museum, or were there just a few items?

When you're brand-spanking new to a platform or technology then by all means, write hundreds of throwaway programs, get some practice (and if possible, some instruction) before ever laying hands on a critical project.

Do not hack away at and rush out production systems because "quantity always trumps quality", as the message here unfortunately seems to be. It's honestly amazing how some people can interpret just about any statement to be a confirmation of their existing beliefs.

doesn't this concept thoroughly rely on the individuals concerned being inept? you don't gain much experience from just raw practice after a while... learning curves generally start to level off.

the example uses students for a reason i think...

http://www.scottberkun.com/essays/ is a fabulous source of good-quality project/person/etc articles. Go read.

I think there is a middle ground to all the things Jeff mentioned - quality v quantity? Well, a bit of both is preferable to only one of the other. (though, obviously you will get better the more you do, that doesn't mean the stuff you did a long time ago is any better than it was when you first wrote it)(it also means you should resist changes to languages, platforms etc. Your new C# code will be much poorer quality than your old VB code. Interesting concept that doesn't get enough attention in this world of constantly changing software systems)

Craft or Engineering? Well, software requires a bit of both there too.

If you have a bunch of house painters, this is true.

If you have a true artist, I'm guessing it's not.

See the problem is that programming IS an art. The only way non-artists can actually create an art is to throw out 100 versions, write tests to make sure that they pass, etc.

It's kinda like the monkeys writing Shakespeare.

Or you can get one artist with a crew of house painters to follow his instructions and create art in a more deliberate manor.

In order to appreciate (or sometimes even see) art of any type, it takes a little training. To train a non-artist to see the art in paintings takes a bit of work. It would take the same amount of work for him to see the art in code--but nobody even recognizes that this would be beneficial

Code that makes a perfect, extensible and pretty much bug-free system is, upon shipping, pretty much indistinguishable from a pile of crap tethered together by monkeys that passes the tests. One will fall apart and take an ungodly amount of effort to maintain, the other will save hundreds of thousands of dollars in programmer time and easily evolve to solve bigger problems.

But most people will never see the difference. Those associated with the crap will just say "Software sucks".

If you are lucky enough to be on a team with an artist and you have significant experience yourself, you will probably see it, but that's pretty rare (I've worked with maybe 1 or 2 in 20 years).

How many artists do you think get to work with masters?

Code as art is preposterous.

Insofar as Soviet-era buildings are functional, they're also butt ugly. Architects and builders can create beautiful buildings, and people appreciate a beautiful, well constructed building over an ugly one that's held together with duct tape. Coders should strive to write beautiful, solid code and present them to users with beautiful interfaces.

Code is not art. You are not an artist. Stop pretending and take yourself seriously.

Nutshell: Extensive practice is a necessary but not sufficient condition for significant improvement.

http://www.etymonline.com/index.php?term=technology

Given the meaning of the root word 'Tech,' programming should be considered an Art _and_ a Craft. Especially if you're good at it.

To all of you code "artists"...

Keep on brute force coding. You will be a starving artist when your work get shipped to India. Companies want effenciency. Companies want assets. Brute force coding is neither.

When the pearls surface, you can rejoice when MS cuts you out with their next service pak release or like minded marketeers reskin your app to take your cake.

Nice article...well written..two thumbs up!!!

This is tempting as a contraian idea, but it's wrong...

Software developers should read Pirsigs book, 'Zen and the Art of Motorcycle Maintenance' to get the truth about quality.

Turning out a bunch of crap is great for learning, but when it comes time to produce a real product, the focus needs to change....

Another Jeff Atwood "smackdown" blog post. Take extreme position Quantiy > Quality and get a reaction. Whether it's positive or negative, it doesn't matter, because they all help pay the bills.

Exactly what I expected from you, Jeff, the "smackdown" blogger.

The entire premise is wrong. Bach and Mozart wrote hundreds of pieces each(i.e. practice is what matters). Beethoven wrote relatively few compared to other composers, yet Symphonies no. 3,5 and 9 revolutionized the form of the symphony.

An inventor like Edison could try hundreds of things before perfecting a final product. But a physicist like Newton would never publish something without being 99% certain that he was right.

Jeff says "If you aren't building, you aren't learning." I'll concede that point. But that does not prove the reverse. Just because you are programming doesn't mean that you are learning. Many, if not most of the programmers who have been programming for 15 years create spaghetti code. Yeah, it works, but try coming in afterwards.

Way to go Jeff. You took two things in quality and quantity that are mostly cooperative in nature and turned them against one another.

But I guess that's what I should expect from a "smackdown" blogger.

I think the point of the article was:

Quantity (code iterations) => Produces Quality

Start writing code, refactor until reasonable quantity is reached.

More code doesn't mean more quantity, it probably means more bugs!

Also, I think writing code without spend some time on design is a waste of time and leads to spaghetti code.

Some effort should be spent on design up front, but don't tread water there.

The moral of the story: There is no such thing as perfect code or a perfect system. I think someone said "continous improvement". Contineous improvement of code, that is what should be strived for.

You can't improve without doing. But the real improvement comes with mentoring, reviewing, and applied training.

I agree with Jon Raynor here:

This is only true given certain circumstances. I deal a lot with manufacturing in China, and this experience has taught me that quantity can actually reduce your ability to learn.

What happens is that with so much effort being placed on getting something, ANYTHING out the door, the team will never stop to analyze the process, so they rarely learn, improve, etc..

Although not wrong, this is a dangerously vague lesson.

Its about learning from mistakes, understanding the bigger picture and purpose.

There is one more synonym: when a group of people asked to make an umbrella, they ended up delivering some thing closer to a parachute (neither it worked properly)

This comes also closer to Agile and Scrum practices, to build on a conceptual model, and ensure that its perceived and practically right in every iteration.

This also means that the development does not deliver few APIs in first release and few in next etc. rather delivering the conceptual model that can be understood, felt, and continued in every delivery/improvement.
So yes there is good quantity of code that is developed, some used some thrown out, before we eventually see feature out.

Do it right the first time!, well all are in search of a proof for this from an angle write the code to the perfect once ! But in reality we still do it right, but that right changes with our leanings.

And in current scenario if NOT FAST, its OUT of the race.

We can learn from the Hardware, electronic and home appliances industry.

I think Jeff has made an error in judgement in wording the article the way he did. Maybe it would be more obvious if he'd had links to articles on TDD or something else that leans away from the traditional waterfall design phase, rather than giving the impression (at least to new programmers) that they should simply "hack until they learn something". Saying "quantity always trumps quality" is a bit vague and conjures images of SPAM, dot-com-boom-era junk sites, badly written games, etc. I realize it makes sense for blogging and it *kinda* seems like he's talking about trying to design the "perfect website" and how just putting something out there is more important - which I'd agree with. But make it clear man! The quality of this post is well below par! :p

Just thought I'd chime in, since this is a topic I feel pretty strongly about....(http://kodecraft.blogspot.com/2008/06/art-or-science.html)

My argument in my blog post is that systems development has both traits of art and science in it, and that really it probably fits in to a category all its own - with really no precedent for the type of activity that it actually is.

One of the traits that compares to art is that it is NOT something you learn by reading a book or whatever.....the truly productive developers are those that have used the technology and have far more tools in their toolchest than they could even describe to you in words. It's intuitive, it's practiced, it's not something that comes from a manual.....so go code, if you want to become a great coder..... go sit in a classroom if you want to become a great teacher(not that there is anything wrong with either).....

Yeah, the title of the post was a little disconcerting - but I think it accomplished what was probably intended - to drum up a little interest.... quantity doesn't trump quality.... quantity develops quality... :)

i pity the guy who has to 'maintain' the first few pots of the quantity group ;)

Is everything OK Jeff? I don't remember it ever taking this long between posts.

Like most extremely simplistic axioms "Quantity always trumps quality" ignores the complexity of the real world. Sure, if you are going to be paralyzed by analysis then you may not produce much if any code at all - I have seen that. I have also seen the other extreme where a coder has written piles and piles of steaming crap that most people won't touch with a twenty foot pole much less a ten foot pole.

The balance lies in between somewhere. *Some* thought should be given to the design, but the mature coder knows when to start coding out their ideas while still thinking about design and quality.

This is not a binary problem; it is not either quality or quantity. Both can be arrived at. A balance of analysis, experience and rolling up the sleeves and writing code can result in both quality and quantity.

Stating that "Quantity always trumps quality" isn't all that helpful, and may be harmful to someone who doesn't have the experience necessary to grok the underlying realities.

Quality is not achieved with quantity in the first atempt, but quality is still more important than quantity. Over time the overall quality of first atempts should improve instead of writing everything from scratch every time with ad hoc process.

The problem with this hypothesis is that everyone, even the practitioner can recognise a crap pot when he sees (or builds) one; whereas many people who write software that appears to work think they have produced quality. They cannot learn from mistakes until they know they have made mistakes, and in software that can be a long and expensive road to take. Software is just more complex that pottery.

Yea, this is a bit misleading.. I side with the Quantity isn't always better than Quality argument, as the type of work is based on a skill level of the person. You kind of have to look at this as something that occurs over time. In the beginning, you don't know what the hell you're doing, so by doing everything a lot, you get familiar with the basics, and start to see what does and what doesn't work and the outcomes of each choice. But as you start to get familiar and learn the pros and cons of everything you're doing, you eventually realize that lots of rocks might kill a single bird, but a well placed rock can kill two birds in one. Thus, you start to critically think about your actions (what is the most efficient way to do something, what is the most appropriate way, etc) and you start doing quality work which is more rewarding once you understand what all your options and consequences are.

In this way, we can see that in the beginning you need a lot of quantity work to build a foundation, then you'll progress to the point that you need a lot of quality work to reinforce and make improvements on that foundation in order to get better. Once you get to the master level, we see that the scale between quantity/quality of work evens out. There was actually a really good article on the two plus two forums about the different levels a poker player goes through that is very similar to what I've said above.

I hate to shamelessly self promote my own stuff, but instrumental music is proven to help concentration and I wrote and released an entire instrumental album by myself, playing all the instruments and mixing it all using Cubase.

Check it out, a lot of my friends code to it. I only tried it once and I couldn't get over "I wish I had done this, I should have tried this instead," etc.

http://www.amazon.com/Infinity/dp/B001CX3BX2/ref=dm_ap_alb1?ie=UTF8&qid=1217586935&sr=8-1

What could be better to code by than an album written entirely by a Software Engineer?