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.
Does the same principle apply to blog content?
Charles on August 3, 2008 2:41 AMRead 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.
Bob on August 3, 2008 3:13 AMWow, this blog post is so bad that it should be criminal.
Joe Chung on August 3, 2008 3:18 AMWhen 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.
Beth on August 3, 2008 3:41 AMIt'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.
David from Oz on August 3, 2008 3:43 AMOkay, 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.
Jazz on August 3, 2008 4:17 AMI 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.
Mike on August 3, 2008 4:23 AMThe 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.
No-Name Timmy on August 3, 2008 4:35 AMSo 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?
Graham Stewart on August 3, 2008 5:03 AMPoint 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'.
Vaibhav on August 3, 2008 5:05 AMI 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.
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.
matthijs on August 3, 2008 5:15 AMJust 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.
bbald123 on August 3, 2008 5:48 AMI 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...
Mike on August 3, 2008 6:02 AMI 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.
Vincent on August 3, 2008 6:02 AM 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).
Pete Kirkham on August 3, 2008 6:04 AM 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?
xxx on August 3, 2008 6:14 AMFire and motion (Joel)?
Marko Dumic on August 3, 2008 6:24 AMOne 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.
Doug on August 3, 2008 6:41 AMHi 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.
Zan on August 3, 2008 6:45 AMThis 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.
Scott on August 3, 2008 6:52 AMI 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.
sean on August 3, 2008 6:54 AMThat 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.
Thomas Winsnes on August 3, 2008 6:57 AMSome 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.
rjs on August 3, 2008 7:10 AMYou 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.
shash on August 3, 2008 7:17 AM@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 ;-)
Vincent on August 3, 2008 7:21 AMWe could just sum up the storry with three words: learning by doing.
Jan on August 3, 2008 7:44 AMPractice 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.
Len on August 3, 2008 7:46 AMI 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.
pete on August 3, 2008 8:26 AMLearning 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.
David Sidlinger on August 3, 2008 8:31 AMAll 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.
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.
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.
Ted on August 3, 2008 8:53 AMGreat 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.
In other word, suck and see.
Actually this is partly what I do.
Andy Wong on August 3, 2008 8:59 AM@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?
mm on August 3, 2008 9:02 AM@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
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.
Greg on August 3, 2008 9:08 AMIt'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.
robot on August 3, 2008 9:19 AMIn 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.
robot on August 3, 2008 9:21 AMThis assumes that everyone learns from their mistakes, or more importantly recognizes when they have done so.
Mark Roddy on August 3, 2008 9:24 AMhave 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...
Anthoney on August 3, 2008 9:47 AM
Apparently, quantity (the Sherman Tank) beat quality (the Panzer Tank) way back in WWII.
Has engineering run it's course... almost.
I'm becoming a student and proponent of 'Erlang' ... there's new interest in this software engine due to the rise of multi-core processors. Erlang accepts that software programmers aren't perfect and will develop buggy code. Instead of charging the programmer with anticipating all possible faults, Erlang just lets the process timeout, die, and be reborn with a shiny fresh new one. This is the fault tolerance. With no globals variables (functional programming) Erlang is highly scalable. And with the Erlang engine having two 'slots' for each module (old running and new running) it allows for system upgrades, corrections and improvements without a takedown/reboot/relaunch/whathaveyou. When you populate the 'new' slot, the stack 'pops' unroll from the 'old' stack, but the stack 'pushes' come from the new slot. When the old stack is drained, I suppose the new slot becomes the 'old' slot and the 'new' slot is emptied.
Has engineering run it's course... almost. When we have mobile thinking robots (cognibots) they'll be 'grown up and trained' rather than programmed. Or, both, kinda like people are today. So they'll need psychologists more than engineers to deal with those things.
This is curious, but certainly seems to be true. The act of writing code really seems to improve the code you write.
However this this is true so long as you don't switch your brain off while writing. I think people need to be constantly questioning whether the code they are writing is the best way to do things.
David Cameron on August 3, 2008 10:02 AMJeff, I think you're using the analogy incorrectly and it's perhaps not even appropriate.
Take a computer science class. Give group A the task to write as many 'useful' programs as possible, give group B the task to write one (perfect) useful program.
The analogy works in this case, you will find some 'better' smaller programs I am sure.
However consider adding an additional task the next day which would work in software but not for pottery, tell group A to make all your programs work together, let group B continue to work on their program.
Which group's final product will be better? I'd suggest that the result would be much more variable.
I'm more of an and person than an or person, and I've been saying quality in quantity for awhile — it's so true that by amassing experience, your quantity goes up. Generally, instead of cramming every idea that comes midstream into a single project, I prefer to save ideas for future projects and build them into what I describe as a stepping-stone narrative.
Torley Lives on August 3, 2008 10:16 AMAnyone who's done ceramics know it's better to make lighter pots, not heavier ones.
josh on August 3, 2008 10:19 AMSadly 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?
Novice Programmer on August 3, 2008 10:36 AMSo... anecdotes are now the basis of engineering principles?
Powerlord on August 3, 2008 10:47 AMGreat article and most of the comments give great advise too :)
Bunny got Blog on August 3, 2008 10:58 AMPlay this 1000x
Earl Scruggs on August 3, 2008 11:02 AMJeff,
just wondering if you left out a few key paragraphs there in order to get the reaction above?
I whole heartily disagree with you Jeff, and am really disappointed that you would condone such a practice. The worst thing that any programmer can do to produce better quality code is to write more sub-quality code. Although your argument seems to be if your right more code you will inevitably get better at it, this logic has an inherent flaw. This flaw is: as people learn to write code, or learn to do any activity, they will form habits that they will continue to utilize in the future. The more they do the more these patterns become ingrained, as is natural with any sort of repetitive process. To change these habits and patterns usually takes large amounts of conscious effort and time. Therefore, it is only natural that the more bad code some one writes the more bad code they will continue to produce. This is akin to the infinite number of monkeys continuously typing producing the entire works of Shakespeare fallacy. It will never happen.
On the other hand, quality is a function of process and process refinement. Specifically, this refinement should be in comparison to others with more experience and the known ability to continuously produce quality product. In the end, quality inherently requires a substantial amount of self-introspection, an ability to admit that you are not as good as you think, and the willingness/determination to change the habits that you identify as lacking quality.
A large quantity of sub-par product is just that, sub-par product. Nothing more, nothing less. Quality product may take longer to design and produce, but in the end it will last longer, perform better, be infinitely more maintainable, and lastly be substantially more testable. Sub-par code is none of these things and never will be. No amount of quantity will ever improve a sub-quality situation. If anything, it may make the situation worse due to the wasted time taken to produce it, and the increased amount of time needed to rectify the situation if it can be done at all.
Matt Presson on August 3, 2008 11:38 AMI'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.
Chris King on August 3, 2008 11:48 AMI'm a little disappointed with the quality of the posts lately and therefore am doubtfull if quality comes with quantity.
Rene on August 3, 2008 11:59 AMI 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.
itsmatt on August 3, 2008 12:10 PMThat's why I love this blog...
:)
Completely agree.
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).
Nathan on August 3, 2008 12:24 PMLooks 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.
Vaibhav on August 3, 2008 12:35 PMIt'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.
John on August 3, 2008 12:36 PMYeah 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. ;;)
Mihai on August 3, 2008 12:51 PMI 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.
Collin Cusce on August 3, 2008 1:19 PMI 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.
Derek Andrews on August 4, 2008 2:10 AMIs 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
TomS on August 4, 2008 2:16 AMThe 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 KR 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 :)
BugFree on August 4, 2008 2:32 AMWhat 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?
asdf on August 4, 2008 2:49 AMCraft 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)
Brian Finnerty on August 4, 2008 2:53 AM@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.
Tom on August 4, 2008 3:05 AMWith 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.
Spencer on August 4, 2008 3:07 AMGo 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. :-)
T.E.D. on August 4, 2008 3:39 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.
chicken on August 4, 2008 3:53 AMJeff 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.
eggonmyface on August 4, 2008 4:07 AM@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
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.
Mecki on August 4, 2008 4:14 AMQuantity 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?
Harry on August 4, 2008 4:22 AMJeff,
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.
Kramii on August 4, 2008 4:28 AMIn 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.
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.
Quantity always trumps quality
counter-example: this blog.
Sorry, could not resist :-)
LKM on August 4, 2008 5:18 AMQuantity always trumps quality.
Worst. Advice. Ever.
Read the Mythical Man-Month.
Bill K on August 4, 2008 5:22 AMAnd 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.
http://pastorgeek.blogspot.com/2008/08/no-no-and-thrice-no.html
Pastor Geek on August 4, 2008 5:38 AM[...]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.
Vinzent Hoefler on August 4, 2008 6:15 AMPractice 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.
Jim C on August 4, 2008 7:05 AMThere'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.
Dave on August 4, 2008 7:06 AMWhile 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.
Some Random on August 4, 2008 7:19 AMSorry, 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.
mike on August 4, 2008 7:20 AMThe comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |