Hiring Good Programmers Matters

Doctor O writes "Joel Spolsky (of joelonsoftware fame) has some good points and fun with numbers on the quality of programmers and whether it is more profitable to go with cheap or good programmers. His point is that a good programmer will simply create code of a quality that average programmers never can create. An interesting read."

Comments

The answer depends

[SpaceCadetTrav]

Are you trying to build a good application or a cheap application?

Re:The answer depends

[anthony_dipierro]

Not really. You'll spend far more money building an application with poor programmers regardless of the quality of the application. That is, if the poor programmers are ever able to finish at all.

Re:The answer depends

[TurtleQ]

As Joel points out, you can have both. He states that, unlike physical products, adding quality to software does not make the software expensive. This is because the cost of "super-programmers" can be divided among the thousands/millions of software licenses sold. The programming cost is fixed, so making it high quality may cost only pennies per sale.

Re:The answer depends

[Jace of Fuse!]

Isn't there already an opened source implimentation of "Hello World"?

Re:The answer depends

[certron]

Although, without bad programmers, we wouldn't have The Daily WTF.

Sometimes a person's purpose in life is to serve as an example to others. What kind of example is another matter entirely...

Re:The answer depends

[Dorsai42]

No, "Hello World" is patented ;-)

Re:The answer depends

[dusik]

Yeah, you'll notice that a team of cheap programmers writes it like:

printf("Hello world!\n");

// 3 cheap coders x $0.05 = $0.15

A single programming Guru will write it as:

/*
* Hello world!
* Copyright (c) 2005 John "Code Guru" Doe
*
* This programme tells the computer to say hello
* to the world, using correct Engligh grammar.
* It should look like:
*
*     Hello, world!
*
* NOTES
*
*  The programme is limited to one way in which
* it greets the world.  In version 2.0 we may
* include another variant of the phrase.  We
* will need an advanced AI engine for the task.
*
* BUGS
*
*  The punctuation is not entirely correct.
* The programme skips the comma between
* "Hello" and "world".
*
* TODO
*
*  Needs more testing.
*/

// Greet the world.  To do that, we make the
// computer say "Hello, world!".
printf("Hello world!\n");

// 1 guru coder x $80/hr x 8 hours = $640.00

Re:The answer depends

[Marc Rochkind]

Well, many people would call me a "guru programmer," and there's no way I would do this for anything like $80 x 8 hours.

You need error-checking on printf and an error log for the error message, you need to internationalize and localize the string, you need both user and maintenance documentation, and you need a client-server architecture. Not to mention that you seem to have jumped into the project without written requirements, a specification, and usability testing.

This would take about a month at my standard rate of $200/hr.

Re:The answer depends

[heatdeath]

Actually, in some kinds of applications, poor programmers are actually on par or better than smarter programmers. Usually you do your best when you're writing code that is easy enough to understand, but hard enough to keep you interested. I, for one, have no patience for writing simple test UIs, for example, or webpages. But some other people find it challenging enough to keep them interested.

Re:The answer depends

[Dwonis]

Client-server architectures are *so* 1990s. You need a "peer-to-peer" architecture now...

Re:The answer depends

[Javagator]

Check out Petzold's Windows Programming in C#. Hello World is copyrighted. Seriously.

Re:The answer depends

[Savantissimo]

Joel is clearly right about the quality and speed of the programming depending entirely on the quality of the programmers. But then he pulls a fast one and assumes that those same people are the best at anticipating what users want and designing the parts of the software that the user interacts with, and that is a rather questionable assumption. How many times have you seen a beautiful interface with unstable code (many media players come to mind) or a crappy interface with code that is like Bach in bytes (TeX, anyone?). There's a lot more that's important in making great software than coding.

My pet theory - and I admit I'm talking out my ass here - is that managing new software development ought to go like this:

1. Decide what you are going to make. Get a reality check from the intended audience. Don't assume that everyone likes or needs what a super-programmer thinks is spiffy.

2. Design and mock-up all the static parts of the user interface and informally specify user-visible behaviors. Have someone who understands visual design and industrial psychology take the lead in directing the UI design with the programmers in a supporting role and management only there to back up the designer's decisions when requested. Get the best such person you can find, even if you think you can't afford her. This person is as important as everybody else on the project put together. Come up with as many radical variations as possible the first couple times through. Be bold and elegant and try to come up with things the user didn't even know she wanted. Have the UI design person get user feedback with the programmers present but with the understanding that they are there to find ways to make what the designer wants and the user needs happen and not to raise problems that programmers can solve on their own. The UI guy needs to be ruthless in excluding things that will get in the way, no matter how cool the programmers think the feature is. Repeat step 2 until the programmers start to lose their minds or the design converges in detail.

3. Formally specify all user-visible behavior by writing the complete user documentation before the first line of code gets written. Have the UI designer and the tech writer work together on the outline and have the programmers looking over the writer's shoulder as the bulk of the text is written. If there is no tech writer, get the UI person to do it, if possible. Check with real users again to make sure it makes sense to them.

4. Then let the programmers do their thing. Having hired good people, don't tell them how to factor or comment or code or what languages they should use. Let them add things only so long as it does not affect the user. (General solutions for specific problems, for example.) Before they start, make them hash out whatever rules they like to ensure quality and maintainability - but hold them to their own rules when things get hairy. Make a significant part of their pay (20%-50%) depend on matching the design and documentation to the UI designer's satisfaction, passing testing and meeting or beating target dates they agreed to when they got full control of the project.

5. Short of correcting a thermonuclear fuckup that would otherwise cripple the software, don't allow any changes, additions or deletions to the design by anybody until the whole thing is out the door as planned.

Is this a stupid or impractical way of doing things? What am I missing?

Re:The answer depends

[tommy]

Writing for Internet Explorer these days is challenging.

Re:The answer depends

[Cederic]

For new software product development, you might get away with that.

Writing software for business use, not a hope of achieving that.

Deadlines of "7 weeks away, because that's when the ads go on TV", requirements of "Has to do everything!", constraints of "No, we can't afford ", changes a week out like "we just signed an agreement, you must integrate with this whole new supplier"...

The only thing you've suggested that's really viable and sensible there is hiring good people. Although you utterly bollocksed that one by trying to link pay to project deliverables - do that and you'll get exactly what you asked for. That's never what you want.

Good people will cope with changing environments and still deliver good work. For once, I'm agreeing with Joel, badly as he did justify his argument.

Re:The answer depends

[mcrbids]

Where you go wrong is that people don't actually know what they want!

I've written projects with HIGHLY detailed specs. I've talked to people high and low. I've gotten signatures in triplicate.

And, those are the projects that BOMB QUICKLY AND PAINFULLY.

The last time I tried that approach, I was told on the DAY OF ROLLOUT after 1.5 months of full-time development that it "wouldn't work" and had to be "totally redone".

I screamed, bitched, complained, waved contracts, specifications and all, before spending another 2.5 months rewriting the application. (while people were using it!)

So, now I do things differently. I spend a bit of time, get a spec, and send out an email to all involved, and wait for 24 hours. Then I write it, knowing full well that it will suck upon delivery, and I make this knowledge apparent, obvious, and common.

Then, the comments come. The text is hard to read. It doesn't include N-ARCANE-FEATURE. When you click the button called "Save", it saves it, but it's not obvious what you are saving.

Whatever. The feedback comes in spades.

So, focus on making updates quick and easy, and listen. That's the Linux way: release early, release often.

People will tell you what they like and don't like. Listen, and release an update when you add new features.

In my flagship product, I've released over 40 releases in a single year. It'd be painful, except that the product updates itself, and it takes me all of about 10 minutes to release. Really.

It costs each user about the same - 5-10 minutes, and they can do it whenever they like.

So, I release early, I release often, and I listen closely to the feedback. Users get what they want, and I get what I want. (Users' money!)

Re:The answer depends

[el_womble]

This makes me worried about government contracts. What happens when there isn't any 'market' and the software is essential to running a country?

In the UK that means that there is a bid. The lowest bidder gets it, they employ the cheapest coders on the planet, farm as much off shore as possible, and then waste millions supporting crappy software. We're now in a situation where we can't trust the government with ANY software creation. They got the passport software wrong (well to start with), they got the tax software wrong (New Tax Credits was a fiasco) and they got the air traffic control wrong (fortunately nobody has died... yet).

What Joel says rings so true that its scary to think that the really important software will NEVER be written like this. But what can you do to remedy the situation? Because there is no market, you can't expect competition to improve the quality of the code, the only incentive being fines to companies when they get it wrong - thats no incentive, that just makes accountants want to do just a good enough job not to get fined.

Do you open source the problem? While I agree that security through obscurity is not security at all, you will never get a country that thinks its a good idea to ahve its tax software open to all to see. There is also Brookes law to deal with and there is still no guarentee that you will attract the best of the best.

Anyways... fascinating article!

Re:The answer depends

[Deusy]

40 releases X 7.5 minutes X 100 users = 30000 minutes (or 500 hours) of employee time for the client.

If only they cared.

Re:The answer depends

[cow-orker]

I, for one, have no patience for writing simple test UIs

Then you might be doing it the wrong way. To make the drudgery interesting again, you generalize to an interesting problem, then solve the original problem as a special case. In the case of UIs, you should probably write a tool that makes writing UIs easier.

"I'd rather write code to write code than write code."

I hope he's wrong

[Anonymous Coward]

I hired a bunch of monkeys and I can't wait for them to write Shakespearian works!

Re:I hope he's wrong

[CrazyTalk]

"It was the best of times, it was the blurst of times. Stupid Monkey!" - Mr. Burns

Re:I hope he's wrong

[Tackhead]

> I hired a bunch of monkeys and I can't wait for them to write Shakespearian works!

Well, I couldn't hire monkeys, but I did the next best thing - outsourced the documentation department.

Romeo, Romeo, why is it that they are calling you Mister Romeo?
You should be talking to your father about getting your name changed,
And if you will not be doing that, oh please just be renewing my contract,
And I will be changing my name to Julie or something else that sounds kind of American!
(Shall I be listening to the on-hold music, or shall I just punch "0" and hope to be transferred?)

They didn't quite meet the "all documentation shall be written in iambic pentameter" part of the specification, but it wasn't bad for $6/hr... and it was still better English than what my alma mater's graduating these days. I'm convinced!

Re:I hope he's wrong

[ikkonoishi]

I heard they got 27 letters so far.

Common Sense

[Tweak232]

Is it really that hard to find out that if someone who is good at what they do will do a better job than someone who is not as good? That seems to be common sense.

I guess it is just me... move along now, nothing to see.

Re:Common Sense

[Daverd]

It's not just whether a good programmer is better than an average programmer. The good programmer is going to be much more expensive to hire than the average programmer. TFA talks about why trying to cut costs on programmers doesn't pay off in the long run.

Can't Go Wrong

[Anonymous Coward]

... sucking up to the egos of your readers.

Yes, you're all great programmers, much better than all the others out there. Especially because you read my posts. We need more people just like you.

Re:Can't Go Wrong

[Pyromage]

I find this article interesting not because it sucks up to programmer egos - which it does - but because, unlike many other articles, it brings in some relatively hard data to support the up-suckage.

Consider Paul Graham, who could be accused of writing programmer ego-stroking articles. They are both good writers, but I like that Joel (at least here) tries to support the theory. He doesn't say "Some programmers are fundamentally better", which is a fairly wide-spread folk belief, backed only anecdotally usually. Instead, Joel says "Are some programmer's fundamentally better? Here's some data that suggests just that".

On a seperate note, a lot of other posters here are saying "Who's Joel?" and "Why should I listen to some guy I've never heard of?". Well, that's a silly argument against whatever he might be saying in your article of choice. Remember that ESR was a nobody once; he seems to be primarily noted for writing the Cathedral and the Bazaar. Similarly with Joel: he's worked on a few software projects, though you may have never heard his name, and he writes well, and his articles make sense. To me anyway: you may disagree, but at least then you're disagreeing based on content, not based on "I've never heard of him so he must be some jackass upstart know-it-all."

Re:Can't Go Wrong

[An Onerous Coward]

Speak for yourself, Mr. Ego. Me, I looked at the story summary and saw my entire short career crashing down around me.

Just pack my job up and move it to India now. Apparently, I won't be needing it.

Re:Can't Go Wrong

[ergo98]

... sucking up to the egos of your readers.

Interesting that you say this given that a raging debate on JOS during the release week of this article featured an endless stream of readers mortally offended that Joel casually dismissed service type developers (e.g. the financial industry, etc). The vast majority of "developers" out there don't work for shrinkwrap shops, but rather get their bread and butter making VB forms and so on, and many of these people were offended by Joel's article.

versus

[rd4tech]

A good, very intelligent and experienced programmer can develop scores of times faster than the average one, because:
- There isn't a need to go and ask simple questions all the time around.
- Development experience gives a 'mental' outline of what the end thing will look like
- Intelligence comes handy when one is 5 level deep in a nested function (which can't be simplified) and trying to add another 2 levels at once.

Re:versus

[unavailable]

- Intelligence comes handy when one is 5 level deep in a nested function (which can't be simplified) and trying to add another 2 levels at once.

Yeah, I'm sure it does. Or maybe that good inteligence should not be wasted on 7 level deep functions that need rewriting anyway?

The Linux Kernel coding style does have an insight on this issue:

Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.

Cost of Quality

[overshoot]

The argument applies across the board with techies in the design end of things. Throwing bodies at a problem generally makes schedules slip even in the design state; what it does to the test and qualification stages is much worse.

My experience with this is in the IC design part of the world, but the rule remains: you're better off with half the people but good ones.

If you want to add bodies, let them do review work. It actually does contribute to quality, and has the added benefit of making better engineers out of the reviewers (and, IMNSOHO, of those who know that their work is going to be reviewed, too.)

Re:Cost of Quality

[pvera]

This cannot be stressed enough: throwing more bodies into the problem only makes the project last longer.

It gets worse when outsiders above the project (say, a division manager that is not paying attention to the status reports) decide to listen to hearsay and water cooler talk and use that as criteria to bring more people in:

"The guys in the break room are bitching about the project, we need to bring more php programmers."

Next thing you know, this head guy is talking to everyone except the actual team that knows what is going on.

This happened to us less than a month before delivery. For real. We found by accident that the boss was concerned and was getting ready to shop around for extra PHP people. Small problem: we were not having PHP problems. Our problem was a hosed CVS repository, which is what we were overheard bitching about while making coffee in the break room.

When we told the boss that there was nothing wrong with the code and we were less than two days behind our schedule (which is much more agressive than his) he almost shit a brick.

The lesson? Don't bitch about technical stuff unless it is a controlled environment. We now keep our bitching for our daily walk to pick up lunch. The odds of someone from the office overhearing us and getting half of the information are pretty much nil.

BTW, the boss still came up with a good idea for bringing extra people, since programmers are not needed. He thinks we can bring temps just to do grunt work like filling a bunch of web forms, etc.

Re:Cost of Quality

[Brandybuck]

If you want to add bodies, let them do review work.

Let them do process busy work as well.

A few months back we were too crunched on the schedule, but another project had cancelled so there were loads of bodies available. But putting them to work coding would have destroyed the project. As always, upper management didn't understand that. So when I was asked where I could best use some extra help, I answered truthfully: have someone else write all the freaking documentation and attend all the freaking meetings so I dont' have to. Tada! They listened and I ended up with four extra hours per day to get the work done.

p.s. Of course, management never learns. Another project is slipping and they're throwing people at it as fast as they can cancel projects. Sigh.

The cult of the elite programmer

[BlightThePower]

I'm not buying. Well, if it is true then it really it speaks to the failure of software engineering as a whole. I hire any other sort of engineer, I expect a certain level of competence and a job done to agreed standards. Not all engineers are created equal of course but the point still standards. This strikes me as revelling in a a form of failure quite frankly, there simply shouldn't be such a wide variation of outcome within the application of an engineering discipline.

Yes, but...

[TheOtherAgentM]

Can the good programmer create code that compiles with a message, "Error: Too many errors." like I did in college? Now THAT is hard to do.

Who is Joel?

[daniel_mcl]

Unless this Joel fellow has some sort of long-forgotten historical notability in software engineering, I fail to see why his articles continually show up here. His company, which he repeatedly plugs in his articles, has put out two pieces of software -- a bugtracker and a content management system -- which nobody I've talked to has ever heard of. Does Joel have some insight into programming that everyone reading Slashdot does not?

I suppose, of course, that the same could be said for most tech journalists, most of whom would have a hard time compiling a source tarball. On the other hand, usually tech journalists are reporting on companies' press releases, not writing editorials about software design.

Re:Who is Joel?

[not_anotherFanBoy]

He jumped out of airplanes for the IDF, wrote the spec for VBA while he was the project manager for Excel in the early nineties, started http://www.fogcreek.com/ and made an assload of money.

You can read the rest of his resume here: http://joel.spolsky.com/resume.htm

Re:Who is Joel?

[istartedi]

Shutup. He's cool. Thousands of slashdotters who never had a chance to be cool in any other context now have a priceless opportunity to mimic the in-crowd in highschool by pretending that their pundits of choice have something to say that isn't obvious to anyone with an IQ of 90. Don't blow it for them. These nerds are desperately deprived of coolness and there's no telling what they might do if they don't get their fix.

Re:Who is Joel?

[puetzc]

The replies to this post seem to fall into two catagories:
1. I haven't heard of him, therefore he must not be important and
2. He can think and write, therefore I read his log.

I definitely fall into catagory 2. I am not a programmer, but I work with programmers, request changes from them, and depend on their work. Insights that I gain from his website and his books have lead to more understanding on my part, and better results. That's good enough for me.

Software application development comes down to...

[tokengeekgrrl]

1. You can have it done fast.
2. You can have it done cheap.
3. You can have it fully functional

Now pick 2.

Fast and cheap = means using average and inexpensive programmers and is not fully functional

Fast and fully functional = exceptional programmers and will cost an arm and a leg

Cheap and fully functional = means it will take a long, long, long, long time for the average and inexpensive programmers to build it

The timeline for the application, whether you need it tomorrow or can wait a few years, in addition to the budget determines what kind of programmers you can afford and need to hire.

  - tokengeekgrrl

I agree.

[Rick and Roll]

I agree. In the words of Leon Battista Alberti,

No art, however minor, demands less than total dedication if you want to excel in it.

This means that people who aren't dedicated to their profession won't properly trap errors, will always be calling functions wrong, and won't figure out what their users want. In a word, they won't excel.

If you don't want your software to have nasty bugs, hire good programmers. If you want your software to work beautifully, hire good programmers.

What does 'best' REALLY mean ?

[haute_sauce]

It is not enough to have 'star' engineers, you MUST have dedicated and motivated individuals. Being a good programmer does not imply willingness to work towards a common goal or play well with others. In some ways I would rather have a team of mediocre programmers who were reliable and worked well together than a couple of 'stars' who had thier own agenda.

He forgot something

[vectorian798]

Best working conditions --> Best Programmers --> Best Software --> Profit!

WTF happened to the ??? step!

One remark I do not agree with...

[Hangtime]

Internal, in-house software is rarely important enough to justify hiring rock stars. Nobody hires Dolly Parton to sing at weddings. That's why the most satisfying careers, if you're a software developer, are at actual software companies, not doing IT for some bank.

I agree with the first part of the statement but not necessairly the second. The reason is as someone who has friends in both worlds rarely does the "software house" ever care about your outside life. If fufilled means being challenged, constantly engaged in your work, but constantly on deadline death marches, always-on fire control, and no life outside of work I guess you can call that satisfied. Have a friend who works MS. LOVES his job, but everything in his life revolves around it and the insane hours he keeps there.

Work to Live, Don't Live to Work.

I respect the heck out of Joel but he seems to fall in that second camp. When the tale of your life is told make sure its not about the code you cranked out but the lives and people you touched.

Yeah, but

[rsilvergun]

bad programming saves money now. Good managers save money now, and use this success when moving on to a better job. In this day and age of lateral movement and massive layoffs, where odds are you're not gonna be at that job long enough for hiring good programmers to pay off, why bother?

Re:Elitist Programmers

[anthony_dipierro]

Yes, but an elitist expert will simply spout off the kind of bullshit that an average person never would come up with.

This is my curiosity...

[symbolic]

Does every "good" programmer have a degree in computer science? Are there exceptions? How can a programmer who might be "average" GET to be a "good" programmer? Can mediocre programmers be MADE into good programmers? This guy seems to be suggesting that it's ok to continue the cycle by doing NOTHING to enhance the abilities of these mediocre programmers. What about hiring a couple of good ones, and then some others who can be ACTIVELY mentored? Isn't that how some other professions work? What is medical internship all about? What about the journeyman status in the building trades? It's all about mentoring and moving people to the next level of expertise.

That's because it's a craft, not engineering

[GrahamCox]

I have always seen software "engineering" as a craft, done by craftsmen. There are too many unfixed aspects to be able to really call it engineering or a science. Of course it has elements of those, but it also has elements of art, and that's what makes it a craft. And just as there are wonderful craftsmen who can create a masterpiece of a beautiful chair from wood, there are factories turning out cheap Ikea furniture by the ton. Both might be perfectly functional in terms of parking one's botttom, but in a hundred years time no-one will be seeking out Ikea chairs in antique shops.

Software is much the same. A true craftsmen of the art will produce code that is so tight, so functional and so spare that it is nothing short of beautiful. When was the last time you made something beautiful? We all get the warm fuzzies from time to time when we think we've done good work, but how can you really tell?

My view is that software engineering courses are all very well (not exactly a waste of time), but they might perhaps be the wrong way to turn out good programmers. Perhaps something more like the traditional apprenticeship would serve better - mentoring by someone who is already a craftsman "well versed in the art". I guess the main drawback of this is that most good programmers are often terrible teachers, but that might reflect the lack of a tradition in the field.

Re:That's because it's a craft, not engineering

[JumpSuit Boy]

It is not just programming it is software "design". Design being the inportant word. You don't have a interior designer right out of school redo your house your hire a firm that has some experienced ones and some that are new but are being mentored by the experienced ones. Your right software design/programing is not engineering.

The full saying is...

[DogDude]

You can have your application built cheaply, quickly, or well. Pick two.

Re:The full saying is...

[DogDude]

You pay one or several good developers to develop it in their extra time. They'll charge significantly less since you won't have insane deadlines. And you don't have to pay by the hour. You can say I want these features for this price, with a deadline of xx months out. Or, you pay people to work on various smaller parts of the whole as you have the money.

Let me guess...

[nobodyman]

...You aren't in management, are you?

Seriously though, it is very non-obvious to a good deal of IT Managers. When you perceive software development costs as ultimately a burn on revenue, their conclusion is that you need to minimize said costs (much in the same way that you would seek the lowest-priced landscaping or office-cleaning staff).

my own experiences

[slashdotnickname]

I work in a large group of programmers of varying ages and backgrounds. I believe you can categorize programmers into 2 main groups.

The first, and the majority at our company, are school trained programmers. These are people whose main experience with coding has been either class related (where the emphasis is usually on theoretical applications) or employement related (where the emphasis is usually along the lines of "just get it done").

The second group of programmers, which I'm in, is the hobbyist turned professional. We are people that began programming for fun, and often program on weekends on side-projects. Data structures and interface definitions become part of our regular vocabulary, and it's often hard to talk to programmers in the first group regarding projects.

Also, from my own experiences at work, I can say that it's the smaller second group of programmers that end up carrying most of a software project, both in code output and internal design. Although the first group of programmers tend to do a better job at testing.

Re:my own experiences

[GlassHeart]

I'm a hobbying programmer who later got a lot of formal schooling. What does that make me?

Re:my own experiences

[TapeCutter]

Employed.

The Google strategy

[restive]

Say what you like about this being dribble, but this is exactly what Google is doing, betting the farm on the long-term value of the cream of the crop.

Re:The Google strategy

[patio11]

And now that they had the IPO, they can bet other people's farms, too! :)

Re:And exactly what is a 'good' programmer?

[humankind]

Here's what I think is the difference between a good programmer and a bad programmer:

1. It has nothing to do with money. You can find good quality developers at both ends of the pay spectrum. In fact, I adamantely believe that the further you get towards the high end of the pay spectrum, the worst the quality is. Too cheap is bad too, but not as bad as too expensive.

2. A good programmer isn't limited to a narrow set of tools or technologies. He will pick the best platform and language/tools based on the application's needs. A bad programmer is one who only knows a small subset of technology and ends up forcing applications to operate within the confines of resources which limit stability, flexibility, performance and productivity.

3. A good programmer spends a lot of time researching the project before ever writing a single line of code. A good programmer demands the client/employer be as detailed as possible regarding the specs of the application. A bad programmer is comfortable with ambiguity relating to product specs. A good programmer, in lieu of getting detailed specs from the client, will create his own outline of what the application will involve and make it finite before coding even starts and make sure the client signs off. Good programmers don't tolerate ambiguity in specs.

4. A good programmer/sub-contractor is more likely to charge a flat rate for the development of the project than an ambiguous time-based wage (but all sub-contractors have to have provisions to deal with project creep and problem clients).

5. Good programmers expose bugs in applications and platforms. Bad programmers create them where they didn't exist.

6. Good programmers always exceed the client's expectations in terms of flexibility and versatility. Bad programmers tend to literally interpret feature lists and make program structure more finite than modular.

and last but by no means least...

7. Good programmers ALWAYS DOCUMENT THEIR CODE WELL! Bad programmers take great pride in making sure nobody can understand what they're doing.

Re:Elitist Programmers

[Skasta]

He makes a note on another post saying that in the original paper Ziv was first author, which is way he lists it as ZLW.

The other side of things

[SuperKendall]

Regardless of what software he has put out or what other projects he has worked on, his blog (JoelOnSoftware) has been read by many developers I've come across - at least the good ones...

I tend to judge him by what he has said more than any experience with software he has written or managed. And really his blog has very good insights on software that other people ignore at their peril - this particular story is no exception to that rule.

just because he also has a bit of the marketer in him (understandable since he owns a business) does not automatically mean he does not know what hes talking about in regards to programming.

So would you disagree with his assertion that a higher quality developer can produce code that would never come from a mediocre one?

Re:I Couldn't Agree More

[Trillan]

I agree that easier-to-use tools are making it easier for poor programmers to both sneak in and through their careers without being caught for the frauds they are. But at the same time, at least some of the easy-to-use tools are... easier to use. For experts, too.

I actually have a thought on this: Requiring applicants to write something in a pseudo-language. The language is defined on a handful of pages given to him, and he has to solve a couple simple problems in that language. I think it would be a great barrier to block idiots from getting in.

Re:Software application development comes down to.

[Xugumad]

Another point to keep in mind that not all your programmers have to the above average, or even average. For example, we have a student helping out over summer. She just doesn't have the breadth of experience for us to trust her with architecture design or the most complex programming tasks, but there are lots of simpler, straight forward jobs that she can do. And working at around half my salary (per hour), she's a hell of a lot cheaper than hiring a graduate programmer with several years experience.

Good programmer = terrible teacher?

[Anonymous Brave Guy]

This was an interesting observation:

I guess the main drawback of this is that most good programmers are often terrible teachers, but that might reflect the lack of a tradition in the field.

Something I've found in many aspects of life is that the people who are really good at something tend to be able to explain it, clearly and accurately, to someone less experienced. This is true of almost any field I've ever studied, from mathematics to martial arts, from driving to dancing.

It's interesting that in Japanese, there is little distinction between being very good/experienced at something, and being a teacher of it. If someone in Japan asks you whether you teach programming, and you're the 20 year veteran Senior Software Engineer at your company, the answer is yes even if you don't teach in the English sense. It's simply implicit that by being good at something, you will be teaching those around you as you do it.

I think the difference between someone who's really good at something and someone who's just OK usually comes down to a depth of understanding. One can follow a cookbook of techniques, or regurgitate information they've been fed in the past. The other writes the cookbook, because they've understood the information and worked out how it all fits together.

A corollary of this is that those who truly understand a subject tend to be better able to convey their understanding to others. Because they can see it from more than one point of view, they can adapt their explanation and examples to fit the knowledge and learning preferences of the person they're trying to teach. Those who never reach that level of understanding can repeat what they were told when they were learning themselves, perhaps even in multiple ways they learned from multiple sources, but they can't adapt it, can't see it from different perspectives and present it in different and original lights.

Thus I'm rather surprised that you think most good programmers are terrible teachers. Most programmers may be terrible teachers, but I question whether a good programmer who is unable to pass on that knowledge is really that good at all. It's unwise to generalise completely, because of course teaching requires skills all of its own, but I've met very few great practitioners in any field who weren't also outstanding teachers.

software development costs

[amoeba47]

Is it not true that most of the cost of software comes from it's maintenance? If the code is created well from the beginning, it will be much easier to maintain in the end. Therefore: Good Code = Easy Maintenance = Less Expense

Re:Elitist Programmers

[Vengie]

Original paper was Ziv and Lempel, later (window refresh) refinement by Welsh. I took CS323. I wrote this code. I'm pretty surprised by the number of people here that have NFC and are posting......thanks for not being one of them. (Them being those that lack the FC)

Pick Two... My CEO says to pick Four

[ljkopen]

A few all employee meeting's ago, my companies president was telling us which was the most important:

"We have to be faster... better... cheeper... and REUSABLE..."

All the engineers I was with worked VERY hard to not laugh.

kind of circular

[cahiha]

his blog (JoelOnSoftware) has been read by many developers I've come across - at least the good ones...

"Good" can mean many things. Joel largely represents mainstream views of Windows and Macintosh programmers--the kind of views you might find among Microsoft Office, Microsoft Windows XP kernel, Safari, or even Mozilla developers. If you want to be like one of those developers, then follow his advice. If you think that there is something seriously wrong with that kind of software (as I do), then you would do well to read Joel's writings more critically and assume that some of it is bad advice. Thinking about those issues will still make you a better programmer.

Moron

[HornWumpus]

You've just moved the skill to the algorythm designer. Is your next claim that all algorythms have been designed and written down in a book somewhere? If they are you should find a library even if you have to pay for it.

In the process of moving the skill to the algorythm designer you've made the whole process that much worse. Now the algorythm is being designed by someone who likely has'nt written much code with the current generation of tools, losing all sort of optimizations that CompSci (with a math view) people just can't see.

Programming is an engineering process. In engineering you always operation with incomplete information. If you pretend to have complete information you will screw yourself.

IMHO all self described 'star' programmers should start their careers working for a couple of years maintaining other 'star' programmers work (by that I mean crap code written by someone who thinks their shit don't stink). Arrogant little shits should not be ALLOWED to do design untill they learn humility. This is best accomplished by throwing them into a project that they could not possibly complete unassisted. 'hello world' is usually close to complicated enough.

Call it paying your dues, or call it completing your education.

But do you want to be a great programmer?

[Anonymous Coward]

Been there, done that. I'm one of the few people to become a multimillionare as a programmer. One of my algorithms is in every computer on the Internet. My name is in some textbooks. I have an advanced degree in CS from one of the name schools. I hold several software patents, which bring in royalties. And I spent most of this evening writing real-time C++, even though I made enough to retire twenty years ago.

After forty years of programming, was it worth it? Often I wonder. I've tried very hard to do good work, whether anyone cared or not. Sometimes it paid off. Sometimes it didn't. But always good work.

But I haven't had much of a life. I spent the Summer of Love in a mainframe computer installation. I've never married. Had a few girlfriends, but wasn't really into it. I'm not into nerd culture, either; I hate Star Trek, and haven't seen the new Star Wars. Nor am I a gamer, although I get royalties from technology in games you've probably played.

And not because I'm the sterotypical overweight geek. I work out, and took jazz dance for years. That's not it. It's just my destiny to program. Whether I want to or not.

Re:Software application development comes down to.

[scotty]

I think Joel is arguing that, by having your average cheap programmers, you will *never* accomplish that "fully functional" stage, no matter how long it takes.

Good programmer?

[ms1234]

What is the definition of a good programmer? Someone who can write flawless code? Someone who can think up a solution fast? Someone who can look at the big picture and design the code and solutions to fit the big picture?

Re:Good programmer?

[antispam_ben]

What is the definition of a good programmer? Someone who can write flawless code? Someone who can think up a solution fast?

Excellent qualifications.

Someone who can look at the big picture and design the code and solutions to fit the big picture?

No, this is bad. Looking at the Big Picture is the manager's job, who can't let a Mere Programmer, even a Good one, do that.

That's such a bunch of bullshit

[melted]

First of all, a good dev is not necessarily faster than a bad one. The bad one will do just enough to get by, badly. The good one will make a fucking work of art out of the features he owns and it will be a pleasure to maintain and extend his code. This usually takes more time than "just enough to get by" approach, but this pays off time and time again over the years.

Second of all, if you're five levels deep in the nested function, that's a good indicator that you're not good enough at software design.

Re:That's such a bunch of bullshit

[Anonymous Brave Guy]

First of all, a good dev is not necessarily faster than a bad one.

That's a matter of perspective. If a "good" dev produces work that does the same thing in the same amount of time as an "average" dev, why is he a good dev? (Obviously this has to hold in the long run, and not just at the time of first writing, and usually this is where the difference lies. Clean designs and good documentation practices usually exhibit their greatest benefits during maintenance.)

Second of all, if you're five levels deep in the nested function, that's a good indicator that you're not good enough at software design.

Or that your algorithm is inherently complicated. I work with deeply nested logic all the time, yet the project I work on is very successful, and the developer team here has a good reputation. People who assume we're not good at design because we don't agree with their dogma annoy me.

Eeeeeeewwwww.

[Samrobb]

must drill into memory...
Carmack==talent
Romero==hotty ex-girlfriend

Wow. I don't know what's more disturbing - that Romero was your ex-girlfriend, or that you thought he was hot.

"Ladies and gentlemen, the captain has turned on the 'Don't go there' sign..."

Joel headed up the excel team at Microsoft

[autopr0n]

Joel was the lead developer of Excel at microsoft for a long time, and he also had a hand in the development of VBScript.

Anyway, his articles are the main reason for his fame these days. His company also has a third product, CoPilot, that lets people fix software problems remotely.

Re:Joel headed up the excel team at Microsoft

[mpcooke3]

and he also had a hand in the development of VBScript.

Perhaps thats why he now says companies should hire competant programmers.

Social skills

[pjunold]

It seems to me that the most crucial skills of a good programmer aren't even mentioned the article - the social skills.

When working in a group it's the productivity of the group that counts - not the amount of code that a single member can dish out. And to a large degree I find the group productivity to be unrelated to the individual coding skills of its members.

A good programmer helps develop an atmosphere where:

• It's encouraged to ask for and give help.
• It's encouraged to ask and give design advices.
• It's encouraged to be proud of something clever you made, demonstrate it at the whiteboard and expect your fellow developers to listen.
• It's encouraged to criticize the work of others in a positive way.

A bad programmer then? The guy sitting in the corner who thinks he's a genius(and accordingly don't need no help from anyone) and don't want to admit he's been stuck with the same problem for days. I have zero patience for such wizkids.

Of cause I'm just your average XP hippie...

Speaking from experience...

[Wonderkid]

...it depends on the size of your company or budget. If you are a small organisation, you need experienced, honest, reliable and hard working programmers - because you cannot afford to wait for them to become good, assuming they have the potential in the first place of course. However, a large company can afford to assign less experienced engineers to less critical tasks (and even send them off to college), while allocating the top programmers to mission critical projects.

Other news

[Frankie70]

In other news,
1) Good Carpenters build good furniture
2) Good Architects architect good structures
3) Good Authors write good books

Re:And exactly what is a 'good' programmer?

[Bjarke Roune]

I do not agree.

1. It has nothing to do with money. You can find good quality developers at both ends of the pay spectrum. In fact, I adamantely believe that the further you get towards the high end of the pay spectrum, the worst the quality is. Too cheap is bad too, but not as bad as too expensive.

Maybe you are not guaranteed good programmers by paying alot, but good programmers still cost more. I just do not see how things could be different, except if you are saying that companies are completely unable to recognize quality.

2. A good programmer isn't limited to a narrow set of tools or technologies. He will pick the best platform and language/tools based on the application's needs. A bad programmer is one who only knows a small subset of technology and ends up forcing applications to operate within the confines of resources which limit stability, flexibility, performance and productivity.

A good programmer will not only think of the needs of the application when choosing tools, but will also consider the context he is in. Chossing an unknown and complex tool might well be a very bad idea, even if it fits the job perfectly. I realize that you might intend this to go under "the application's needs".

3. A good programmer spends a lot of time researching the project before ever writing a single line of code. A good programmer demands the client/employer be as detailed as possible regarding the specs of the application. A bad programmer is comfortable with ambiguity relating to product specs. A good programmer, in lieu of getting detailed specs from the client, will create his own outline of what the application will involve and make it finite before coding even starts and make sure the client signs off. Good programmers don't tolerate ambiguity in specs.

Most projects are not of the form "implement a correct compiler for Java" or something equally well defined. In many contexts, demanding exact specifications will result in endless preparations, and as soon as the spec is "perfect", requirements will have changed. Specifications change because needs change and the knowledge of the users and developers increases as the project progresses. This is not a bad thing, it is a very good thing, even if it can be annoying to the programmer. I think eXtreme Programming gets this right: get some code out of the door as quickly as possible so people can try it out.

4. A good programmer/sub-contractor is more likely to charge a flat rate for the development of the project than an ambiguous time-based wage (but all sub-contractors have to have provisions to deal with project creep and problem clients).

Specifications change so a flat fee is a bad idea for everyone.

Good programmers expose bugs in applications and platforms. Bad programmers create them where they didn't exist.

Good programmers are human, so they make mistakes too. Of course they may do it less frequently, but they still do it.

6. Good programmers always exceed the client's expectations in terms of flexibility and versatility. Bad programmers tend to literally interpret feature lists and make program structure more finite than modular.

Unneded flexibility and versatility can increase code complexity, introduce bugs, make the program harder to use in the common case and lengthen development time. It is much better to get the program out there in use quickly, and then implement just those things people actually end up needing. Of course, in some cases things can be made more general "for free", and then the good programmer will try to spot it and do that. Sometimes the flexibility and versatility is really useful og necessary, and only in those caes will the good programmer make the program that way.

7. Good programmers ALWAYS DOCUMENT THEIR CODE WELL! Bad programmers take great pride in making sure nobody can understand what they're doing.

I might agree, depending on what yo

And get catastrophe code like this?

[Moraelin]

Being good and experienced at programming doesn't just involve getting the code done and compiling. It also involves having some clue about stuff like security, good design, and generally knowing a lot more than just how to printf("hello world.")

The corporation I work for had at some point decided to replace an existing, working system with a monstrosity that had more buzzwords. So a team from a BIG corporation contracted the work, and took a couple of years at it, until finally the project was scrapped.

By the time it was scrapped, the code they had produced, although it did compile, had major problems, including fatal security issues. (And it also needed a cluster of two dozen servers to serve the same number of users as the old system did on 1 server. And took several hours to even start or stop. Literally.) Among other problems:

- they consistently assumed that the _only_ way to reach a page was to click on a link, so they didn't have to check rights again when rendering it. The user wouldn't have gotten the link to it, if he didn't already have the rights, right?

Wrong. By such trivial means as just editing the user id in the URL to 0, you could become super-user or change anyone else's password. (E.g., the super-user's.) And basically gain full admin rights to a corporate site.

- they failed _repeatedly_ to quote text displayed on the site. So you could simply type some JavaScript code in a text box, and have it execute (e.g., on mouse-over) in the browser of whoever views that post or offer. Again, one possible and demonstrated use was to steal or change someone's data, including an admin's.

- they failed _repeatedly_ to quote text used in SQL queries. So basically you just needed to input something like '" OR "1"="1' in the search field, and you'd get all the records on the system.

- they failed to even conside "non-repudiation". If a user cancelled their account, a cascaded delete would ensue, deleting _all_ the data about that user or from that user, including contracts. It was suddenly as if that user had never even existed, ordered or paid anything.

Etc.

We're talking about a B2B e-commerce site, with contracts worth millions, not about someone's blog about their cats. And it had gapping holes bigger than the goatse guy, for f**k's sake. As they wanted to ship it, it _literally_ allowed anyone to access any data and escalate their privileges to the max, in just a few kestrokes.

_That_ is a problem with making software with a team of incompetent monkeys. It's not just that they take longer to produce the code, or that it might need more debugging. It's that they just don't have the skill or knowledge to judge (or even consider) the implications of the choices they're doing at each step.

Software houses that care about your life

[sita]

The reason is as someone who has friends in both worlds rarely does the "software house" ever care about your outside life.

We live in different worlds. I have no experience of software product companies that try to consume you. On the contrary, in my experience, software product companies that hire "good programmers" are conscious that they "good programmers" are often "high performers" in several areas that don't include work, and need to be to keep happy, and thus productive. I guess that is because the people who consequently hire "good programmers" are similar themselves (not necessarily programmers, but of the same general disposition).

Re:Does quality matter, though?

[DemonSlayer]

You hire good programmer to make code.
You hire average programmer to make test.
You hire cheap programmer to make documentation.
You hire bad programmer to make coffee.
You hire sexy programmer to make love.
You hire ugly programmer to make installation CD.

The software will be affordable.
Good programmer - high pay but U hire only one.
Average programmer - average pay.
Cheap programmer - low pay.
Bad programmer - under pay.
Sexy programmer - average pay.
Ugly programmer - low pay.

Drowning under a waterfall

[Anonymous Brave Guy]

Is this a stupid or impractical way of doing things? What am I missing?

Not stupid, but naive. Waterfall models went out with the 1980s, because they didn't work.

If there's one great truth the software industry has (mostly) successfully learned in recent years, it is that successful projects must be adaptable, because requirements change. With the possible exception of things like military and medical projects, it's almost never helpful to fix absolute requirements up-front. Any project whose plan involves the words "finished before the first line of code is written" is pretty much doomed to failure before it even starts.

Yes, get user feedback early and often. Yes, get someone who understands UI design to do the UI design, and have someone whose role is to co-ordinate the customer view and the developer view of the project. Yes, give the programmers a clear idea of what you want and letting them get on with providing it. These are all good things.

But you have to do them more than once. Whatever process you use, whether you prefer lightweight or very formal, it needs to be iterative and go in cycles. Unless you're prepared to increase your overheads by at least an order of magnitude, nothing else works.

Not just programmers

[ishmaelflood]

I really liked his attempt at analysis, and particularly liked his attempt to split out the higher quality coders.

I used to run the mechanical engineering section for a small project. We used a lot of contract CAD guys. A good CAD guy was about 4 times more productive than an average one, and would cost 0-30% more, per hour.

With engineers my experience is that the best engineers are roughly 4-10 times faster and more accurate than the average guy, and the bad ones have a negative effect on productivity.

War story: two of us redesigned a system and saved 200 bucks per unit. We make 100 000 units per year. So that's $20 million a year.

Somebody redesigned one of my parts, saving $0.30 per unit. We had to recall several tens of thousands of units because the new design was unsafe. Total cost in excess of 10 million dollars.

I have seen parts with identical functionality. One was designed by an idiot and cost twenty bucks. The other was designed by a competent engineer. $3

conclusions and data seem totally unrelated

[rp]

Joel Spolsky's article first bings up some findings from hard data:

    - programming seems to take almost arbitrarily long; there appears to be next to no limit on maximum time and deviation (except hard deadlines)

    - there is no correlation at all between the time used and the quality of the result

The question is whether quality correlates with other variables than time, more specifically, with the programmer.

So the next step should be: when looking at the scores of individual programmers, do we see consistency? Is there such a thing as a "good" programmer, who scores consistently better quality than the average programmer?

Joel's report becomes a little ambiguous at this point. He selects "the top 25% programmers" without saying how. I'm confident he selected the programmers who took the first 25% of overall (averaged) quality scores. I do not believe he selected the first 25% of results for every exercise, but the wording doesn't completely exclude it.

He reports that, collectively, these top 25% of programmers take almost exactly as much time as the rest (both in maximum and in deviation).

He then leaves the data and starts about the difference between good and average programmers. This is a total non sequitur. Nothing he says about that difference is supported by his analysis.

It might seem at first glance that the analysis supports the notion that there is such a thing as "the good programmer". But it doesn't. Joel doesn't give us any information on whether some programmers perform better than others. He looks at the ones that came out in the top 25% and *calls* them the "best programmers". For all we know, the quality scores were completely random and the programmers that came out on top just got lucky this time. To see if quality of code is correlated with the programmer writing it, we should see if there is any consistency in the difference between individual programmers' scores across exercises. Joel didn't do this. He committed the classical logical error of assuming what he wanted to demonstrate, namely, that there is a difference between "good" and "average" programmers.

For now, let's gloss over this fatal weakness and go along with Joel's (plausible) hypothesis that there is such a thing as a difference between "good" and "average" programmers. We now come to the strong point of the article. Joel was, of course, hoping to find that the programmers who produced (on average) the best quality code were also the faster ones. But they aren't: they are just as slow as the average programmer.

It's to Joel's credit that he doesn't hesitate to report these findings, since in my eyes they are fatal to the hypothesis he started out with.

What these figures prove is that the good programmers (those with good results on average) are just as slow as the average ones. The difference in productivity solely consisted of the fact that the top 25% got better results - but that is not exactly surprising, since it is how they were selected.

Amazingly, Joel draws the opposite conclusion: these same figures are supposed to demonstrate a 5-10 times speed difference between programmers! But that is only when measuring on individual exercises. It is completely unwarranted to draw any conclusions on the speed difference across exercises.

OK, so we don't really see any difference in productivity. "But wait, there is more! (...) No matter how long (mediocre programmers) work, they never produce something as good as what the great programmers can produce."

Um, where exactly did we see this? Did the data provide any evidence that some programmers never find good solutions? Nope. Do some programmers arrive at good solutions all the time? No idea. if they did, I would think they would also work faster than the average programmer, and they don't. SO again, Joel is pulling his statement out of thin air, and the relationship with the data is no more than suggestion.

On the whole, an interesting, but flawed article.

Re:And exactly what is a 'good' programmer?

[humankind]

Obviously you disagree.

I could respond to your arguments tit-for-tat, but I don't really think it's necessary. If I hired you, I suspect I'd end up having to re-do a lot of what you did, because you seem to be very good at coming up with excuses, which is what a good programmer doesn't do. Anyone who thinks that not documenting code is practical in any environment is not someone I'd respect as a "good programmer". Obviously, your milage does vary. Talk to me when you've developed commercial software that has sold millions of copies and recieved numerous honors and awards. I know what that's like.