programming and human factors
by Jeff Atwood
Nathan Bowers pointed me to this five year old Cool Tools entry on the book Art & Fear.
Although I am not at all ready to call software development "art" -- perhaps "craft" would be more appropriate, or "engineering" if you're feeling generous -- the parallels between some of the advice offered here and my experience writing software are profound.
The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the "quantity" group: fifty pound of pots rated an "A", forty pounds a "B", and so on. Those being graded on "quality", however, needed to produce only one pot - albeit a perfect one - to get an "A".Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the "quantity" group was busily churning out piles of work - and learning from their mistakes - the "quality" group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.
Where have I heard this before?
Quantity always trumps quality. That's why the one bit of advice I always give aspiring bloggers is to pick a schedule and stick with it. It's the only advice that matters, because until you've mentally committed to doing it over and over, you will not improve. You can't.
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.
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).
Reed on August 4, 2008 7:20 AMAnd...
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.
mike on August 4, 2008 7:27 AMNotice 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.
A reader on August 4, 2008 7:44 AMIt'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
Robin Day on August 4, 2008 7:57 AMHey 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.
T.E.D. on August 4, 2008 8:17 AMhttp://www.infoq.com/news/2008/08/programming-processes
Donny on August 4, 2008 8:17 AMLike 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.
AC on August 4, 2008 8:21 AMSounds like agile to me.
Ofer on August 4, 2008 8:26 AMlearn 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.
daab on August 4, 2008 8:26 AM 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.
T.E.D. on August 4, 2008 8:31 AMBe Joel, Be Jeff, do HR posts, ad nauseam, blog for people who fear coding
BugFree on August 4, 2008 8:33 AM... 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.
Hutch on August 4, 2008 8:38 AMThe 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.
AC on August 4, 2008 8:38 AMI always enjoy this quote from Stalin, Quantity has a quality all its own.
Sneal on August 4, 2008 8:42 AMCouldn'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.
Karthik on August 4, 2008 8:43 AMFor 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.
Kenneth on August 4, 2008 9:16 AMAlso, 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.
Kenneth on August 4, 2008 9:21 AMIt'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.
just3ws on August 4, 2008 9:37 AMWell 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.
Practicality on August 4, 2008 9:38 AMThis 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?
aProgrammer on August 4, 2008 9:38 AMHaving 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.
Sal on August 4, 2008 9:41 AMWhat'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.
Peter Seale on August 4, 2008 9:42 AMQuantity 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.
Zack on August 4, 2008 9:46 AM
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.
Jim Cooper on August 4, 2008 9:47 AMI 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.
Philip on August 4, 2008 9:51 AMAsk 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...
Kris on August 4, 2008 10:06 AMWhere 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.
RogueCoder on August 4, 2008 10:14 AMI 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.
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.
Nathan Long on August 4, 2008 10:29 AMInteresting. 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.
William on August 4, 2008 11:11 AMYou 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.
Mark Ransom on August 4, 2008 11:16 AMIf 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.
Brad Kaenel on August 4, 2008 11:27 AMJust 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.
Kenneth on August 4, 2008 11:30 AMQuantity 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).
JoshuaD on August 4, 2008 12:40 PMJeff,
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! :)
BrianHall on August 4, 2008 12:55 PMSo who has to maintain the other 49 pounds crappy pots that are made to get the 1 good pot?
Good luck with that strategy.
Rob on August 4, 2008 1:15 PMbullshit. I know a lot of developers in big projects who never see their errors alive, and have no learning curve from writting their crap.
offler on August 4, 2008 1:22 PMDamn 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.
Andrew on August 4, 2008 1:29 PMI 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).
Anders Sandvig on August 4, 2008 1:37 PMI'd like to repeat what No-Name Timmy said.
G on August 5, 2008 2:13 AM@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.
Nik Radford on August 5, 2008 2:35 AMFunny, 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...
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.
None Provided on August 5, 2008 5:03 AMFrom 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!
AC on August 5, 2008 6:17 AMJust 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).
Dave Aronson on August 5, 2008 6:27 AMdoesn'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...
jheriko on August 5, 2008 7:36 AMhttp://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.
AndyB on August 5, 2008 9:46 AMIf 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?
Bill on August 5, 2008 11:02 AMI didn't learn the things the book wanted me to know, and I did learn things not in the book.
Music By Day on August 5, 2008 1:53 PMI 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.
Micah Stevens on August 6, 2008 5:25 AMhttp://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.
Murphy on August 6, 2008 9:23 AM
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.
WarBread on August 6, 2008 9:34 AMWhen 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.
Martin on August 6, 2008 11:00 AMNice article...well written..two thumbs up!!!
Hostmonster on August 6, 2008 11:43 AMThis 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....
JT on August 6, 2008 12:16 PMAnother 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.
John on August 6, 2008 1:51 PMIts 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
SpongeJim on August 7, 2008 6:27 AMJust 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... :)
kyle on August 7, 2008 8:52 AMi pity the guy who has to 'maintain' the first few pots of the quantity group ;)
Marijn on August 7, 2008 11:12 AMIs everything OK Jeff? I don't remember it ever taking this long between posts.
Gio on August 8, 2008 4:20 AMLike 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.
Silvercode on August 9, 2008 11:59 AMThe 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.
Clifford on August 10, 2008 1:20 PMYea, 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.
abel on August 10, 2008 1:20 PMI 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=UTF8qid=1217586935sr=8-1
What could be better to code by than an album written entirely by a Software Engineer?
ploskinj on August 11, 2008 7:17 AMEverybody agrees on quality being better than quantity.
The point made here is that quantity is a way to quality, which is only true if you have the necessary level of brains, drive and interest in programming, in my opinion. The more of these the less quantity work you need to achieve quality.
If it were all down to talent, and no quantity work were required to produce high quality code, then you would never look back at your code and think you could have done the same thing 100 times better in half the number of lines.
Which is why we can all speculate about quantity as much as want, but the 'quantity' group of students did better.
Sagredo: You have made me see this matter so plainly and palpably that if Aristotle's text were not contrary to it - stating clearly that the nerves originate in the heart - I should be forced to admit it to be true.
joe on August 15, 2008 9:52 AMThanks for the post, Jeff!
Even though I agree with the general idea of Practice makes perfect, I do not like the title of the post, Quantity Always Trumps Quality. Perhaps, it could be worded better as Quantity leads to Quality or something similar.
If you pick any type of human activity, you will find that performing a lot of iterations of a particular task can lead to expertise in that task. It is no miracle that a number of good authors are also quite productive. However, the practitioner has to keep the goal of improvement in mind and expend the necessary effort to improve in every iteration for the expertise to develop. If this is not done, then complacency might set in which can slow down or even stop the development of expertise (though the task may still be done well). Another thing the practitioner should do is to analyze the work done in an iteration to learn from it and apply the learning in the next iteration of the task.
Inder P Singh on August 18, 2008 6:42 AMWhat about Quality Quantity at the same time ?
There is people that can code the same mistake over over, and never learn. There is people that code the same slow feature 9 times, and found a new faster solution and use it.
Maybe the solution is applying theory to practice, and not, plain theory or plain practice...
Cheers
mramirez on August 22, 2008 2:16 AMThis blog definitely lies in the Quantity cat. The comments can be good but when it comes to the blog excluding comments, there are much better tech/programming blogs out there that may only write couple posts a year or even no posts at all in a particular year. I still sub them because of RSS I will immediately know when there's something good. As you may have guessed I have not subscribed this blog because it's a quantity blog not a quality blog and quantity = spam.
ubergeek on August 27, 2008 11:03 AMMan. I use the same principle when making music. I feel like if I put too much of myself into it then it just sucks but if I crank out one song a day for a month I end up with 5-10 really sweet songs, or at least GREAT ideas!
Well put, blogger man. Well put.
-Cray0la-
EggNogAdam on September 5, 2008 6:13 AMGreat article Jeff!
I happened to browse upon your site a while back and the ceramic teacher story really stuck in my mind. For a while I was unemployed/freelancing and didn't really know what to do regarding learning new skills or enhancing existing ones, etc. so I adopted the quantity philosophy.
Thanks for spreading the word on the subject :-)
FlexBandit on September 6, 2008 11:53 AMOne thing is missing from the produce quantity argument -- FEEDBACK.
I personally think we'd have to look upon the infinite factors, and infinite examples, infinite given and non-given constraints
to judge whether quality or quantity is superior over one or the other.
In other words my answer is, it depends.
Firstly, We shall note that quantity can't really be a negative number unless represented in verb for, rather adjective.
We shall also note that quality does not exist without quantity, therefore quality is dependant upon quantity.
We should ALWAYS look at quantity first.
Then we should look if there is any quality.
We shall note, quantity can't be of a number zero, for then there will be nothing to compare intitally. However, the quality can be zero because it is dependant of quantity. BUT, We don't know how to judge quality, as quantity officially appears to us as an exact number. Quality is shown to us however we don't know the numerical quantity of the quality itself. We can mentally debate over this, as mentally we can give constraints numerically to quality, however main point being, if debating over this question in terms of physical world, then we don't know exactly whether the quality officially has a numerical value. Thus as I said, it depends on the situation as to whether quality or quantity is superior over the other.
To judge whether quantity vs quality, which is better?
lol quality doesn't exist without quantity.
So the true approach to the Question would be...
Quantity ( step one only) vs. Quality ( step one AND two. consisting of both quality and quantity).
~Emil on December 30, 2008 6:53 AMPart 2 of comments:
where I left off...Quantity(step one) vs. Quality ( step one+ Step two)
Of course we'd have to debate this over it mentally because to compare quality accurately, we'd need to give quality a numerical value ( which is a quantity).
So it'd be quantity vs. the numerical value of the quality given of the initial quantity + the initial quantity.
Of course, the numerical value of quality can only be formed through our mental minds, as physically there is ( so far unless proven wrong)
no official inter-galactical system of finding qualities upon quantities.
We can only use the words none,minimum, less,equal, more, and maximum
to describe and compare qualities of quantities. However this is not accurate enough to judge. We NEEd specific numerical values upon the qualities and a system to find the numerical value.
~Emil on December 30, 2008 7:01 AMPart 3 (final of the initial)
So I conclue, unless the quantities have the same value and one quality is more or less,
We would have to have an official numerical value on the quality to judge whether the quantity or quality is more superior.
Also if we found the numerical values of quality, we'd need a system of putting it into effect.
If A has quantity = 3 quality 5
and B has quantity = 5 quality 3
What mathematical system shall we use?
If quality is added upon quantity A= 8
B = 8
If subtracted then one of the following will have a negative number which wouldnt work out.
If multiplied then both would = 15.
Therefore we need to A: find the official numerical value of the qualities.
And B: use a system of which we can combine quality with quantity.
Only then can we find quantity vs quality.
Thus, I stick with my answer, it depends. :D
I'm a senior in computer engineering and some of our larger projects spanning 2 semesters have revolved around a computer design course in which we implemented an 8086 system that would later interface to an 8051 system using protoboards, soldering, and wire wrapping. Without fail, the highest quality end products are from the students who took the least amount of time and effort to produce their first attempt at the board. As components and peripherals are added to the board, problematic connections, design, and code inevitably lead the board to a state of complete instability and the unfortunate student has little choice but to rip the whole thing apart, delete all but his most basic x86 assembly code, and start from scratch despite being many weeks into the project.
I've personally rebuilt my board 3 major times and my code 4 times, and my last iteration took only 2 weeks to complete all of the code and hardware work, coincidentally my project is of a much higher quality.
Matt on January 2, 2009 1:13 AMIf 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.
Simon on February 6, 2010 10:38 PMThe 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 binvolves high levels of repetition./b
http://money.cnn.com/magazines/fortune/fortune_archive/2006/10/30/8391794/index.htm?
Pat Morrison on February 6, 2010 10:38 PMIt'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.
Aston on February 6, 2010 10:38 PMJust 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.
Jason Bunting on February 6, 2010 10:38 PMWhen 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.
@ 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.
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.
Aaron G on February 6, 2010 10:38 PMI 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.
Thank you for this post. It was exactly what I needed to hear right now.
Dillon on February 6, 2010 10:38 PMGrok the domain and the problem, formulate a good solution, code it, maybe refactor a little as you go if the system will benefit from it.
Code isn't an art because you dive right in and spill your soul into the editor, it's an art because good code is beautiful in its simplicity. Either you'll get lucky and get that the first time around (not often true no matter how good you are), or you'll need to take a few iterations to get it down.
The optimal solution to any given coding problem is the simplest way of expressing the answer for all cases; that's art, *and* good code.
Just my two cents.
Jon on February 6, 2010 10:38 PMYour blog is very motivating. When I was reading it, I get drawn in. I am totally agreed with your thoughts. Thanks for sharing this beautiful thoughts with me.
http://www.business-energy.com.au/>Business Electricity – Compare
Good advice - I'd like to combine it with some kind of testing. That is produce, produce, produce, but test each iteration against some kind of standard you want to attain: academic, technical aesthetic. You certainly don't get better without practice but undirected growth can have negative consequences (viz cancer).
Pearce_ on September 26, 2010 7:08 AMI think the point here is to quit talking and start building so you can go ahead and figure out where you screwed up sooner.
Unless you are so awesome that you never screw up. In which case you shouldn't be writing code.
Thomas Holland on April 4, 2011 2:31 PMThis is like the case where changing an item in the analogy doesn't always result in the same conclusion.
For eg:
The crying baby gets the milk.
The squeaking wheel gets the grease.
Uh... not always. The squeaking wheel may get replaced. So much for the squeaking.
Similarly in this case the Pot example is good but replace that by something else like an AK47 or a nuclear reactor and you can see the analogy comes apart.
I have members in my current team who have been coding for years but still write the same truckload of shit.
Bobby Alexander on April 7, 2011 2:09 AMThe comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |