https://www.joelonsoftware.com/2006/09/06/finding-great-developers-2/
The great software developers, indeed, the best people in every field, are quite simply never on the market.
The average great software developer will apply for, total, maybe, four jobs in their entire career.
The great college graduates get pulled into an internship by a professor with a connection to industry, then they get early offers from that company and never bother applying for any other jobs. If they leave that company, it’s often to go to a startup with a friend, or to follow a great boss to another company, or because they decided they really want to work on, say, Eclipse, because Eclipse is cool, so they look for an Eclipse job at BEA or IBM and then of course they get it because they’re brilliant.
I have three basic methods for how to go about this:
- Go to the mountain
Look for the hot new technology of the day. Last year it was Python; this year it’s Ruby. Go to their conferences where you’ll find early adopters who are curious about new things and always interested in improving.
- Internships
One good way to snag the great people who are never on the job market is to get them before they even realize there is a job market: when they’re in college.
You can either participate in this madness, by recruiting on campus, which is a good thing, don’t get me wrong, or you can subvert it, by trying to get great kids a year or two before they graduate.
I’ve had a lot of success doing it that way at Fog Creek. The process starts every September, when I start using all my resources to track down the best computer science students in the country. I send letters to a couple of hundred Computer Science departments. I track down lists of CS majors who are, at that point, two years away from graduating (usually you have to know someone in the department, a professor or student, to find these lists). Then I write a personal letter to every single CS major that I can find. Not email, a real piece of paper on Fog Creek letterhead, which I sign myself in actual ink. Apparently this is rare enough that it gets a lot of attention. I tell them we have internships and personally invite them to apply. I send email to CS professors and CS alumni, who usually have some kind of CS-majors mailing list that they forward it on to.
Eventually, we get a lot of applications for these internships, and we can have our pick of the crop. In the last couple of years I’ve gotten 200 applications for every internship. We’ll generally winnow that pile of applications down to about 10 (per opening) and then call all those people for a phone interview. Of the people getting past the phone interview, we’ll probably fly two or three out to New York for an in-person interview.
So we give them real work. Hard work. Our interns always work on production code. Sometimes they’re working on the coolest new stuff in the company, which can make the permanent employees a little jealous, but that’s life. One summer we had a team of four interns build a whole new product from the ground up. That internship paid for itself in a matter of months. Even when they’re not building a new product, they’re working on real, shipping code, with some major area of functionality that they are totally, personally responsible for (with experienced mentors to help out, of course).
And then we make sure they have a great time. We host parties and open houses. We get them free housing in a rather nice local dorm where they can make friends from other companies and schools. We have some kind of extra-curricular activity or field trip every week: Broadway musicals (this year they went crazy about Avenue Q), movie openings, museum tours, a boat ride around Manhattan, a Yankees game, and believe it or not one of this year’s favorite things was a trip to Top of the Rock. I mean, it’s just a tall building where you go out on the roof in the middle of Manhattan. You wouldn’t think it would be such an awe-inspiring experience. But it was. A few Fog Creek employees go along on each activity, too.
Anyway, for the ones we really want to hire, there’s no use in waiting. We make an early offer for a full time job, conditional on their graduating. And it’s a great offer. We want them to be able to go back to school, compare notes with their friends, and realize that they’re getting a higher starting salary than anyone else.
Does this mean we’re overpaying? Not at all. You see, the average first year salary has to take into account a certain amount of risk that the person won’t work out. But we’ve already auditioned these kids, and there’s no risk that they won’t be great. We know what they can do. So when we hire them, we have more information about them than any other employer who has only interviewed them. That means we can pay them more money. We have better information, so we’re willing to pay more than employers without that information.
If we’ve done our job right, and we usually have, by this point the intern completely gives up and accepts our offer. Sometimes it takes a little more persuading. Sometimes they want to leave their options open, but the outstanding offer from Fog Creek ensures that the first time they have to wake up at 8:00am and put on a suit for an interview with Oracle, when the alarm goes off, there’s a good chance that they’ll say “why the heck am I getting up at 8:00am and putting on a suit for an interview with Oracle when I already have an excellent job waiting for me at Fog Creek?” And, my hope is, they won’t even bother going to that interview.
- Build your own community*
*hard
...When a Fog Creek employee suggests someone that might be perfect to work for us, we’ll be willing to skip the initial phone screen, but that’s it. We still want them going through all the same interviews and we maintain the same high standards.
https://www.joelonsoftware.com/2006/09/07/a-field-guide-to-developers/
Unfortunately, you can advertise in all the right places, have a fantastic internship program, and interview all you want, but if the great programmers don’t want to work for you, they ain’t gonna come work for you. So this section will serve as a kind of field guide to developers: what they’re looking for, what they like and dislike in a workplace, and what it’s going to take to be a top choice for top developers.
-
Private offices
There’s a strong culture in Silicon Valley that requires you to jam a lot of programmers into a big open space, despite a preponderance of evidence that private offices are far more productive, something which I’ve covered repeatedly on this site. I’m not really getting through to people, I don’t think, because programmers kind of like being social, even if it means they are unproductive, so it’s an uphill battle.
-
The physical workspace
What will they think of our location? How does Buffalo sound, compared to, say, Austin? Do people really want to move to Detroit? If you’re in Buffalo or Detroit, can you at least try to do most of your interviewing in September? When they get to the office, what is the experience like? What do they see? Do they see a clean and exciting place? Is there a nice atrium lobby with live palm trees and a fountain, or does it feel like a government dental clinic in a slum, with dying corn plants and old copies of Newsweek? What do the desks look like? Do programmers have multiple large flat screens or a single CRT? Are the chairs Aerons or Staples Specials?
-
Toys
Similar logic applies for other developer toys. There is simply no reason not to get your developers top of the line computers, at least two large (21″) LCD screens (or one 30″ screen), and give them free rein on Amazon.com to order any technical book they want. These are obvious productivity gains, but more importantly to our discussion here, they’re crucial recruiting tools, especially in a world where most companies treat programmers as interchangeable cogs, typists, really, why do you need such a big monitor and what’s wrong with 15″ CRTs? When I was a kid, …
-
The social life of developers
-
How are programmers treated inside the organization?
-
Who are their colleagues? (By the way, the original hiring rule for Fog Creek, stolen from Microsoft, was “Smart, and Gets Things Done.” Even before we started the company, we realized that we should add a third rule: “Not a jerk.”)
-
Independence and autonomy
-
No politics (When I complained about MacroMan, my boss told me, “Nothing’s gonna derail that train. Give up.” But I kept arguing, and arguing, and arguing—I was fresh out of college, about as unconnected as anyone could be at Microsoft—and eventually people listened to the meat of my arguments and the MacroMan project was shut down. It didn’t matter who I was, it mattered that I was right. That’s the kind of non-political organization that delights programmers.)
-
What am I working on? (Another thing developers like is working on something simple enough or popular enough that they can explain to Aunt Irma, at Thanksgiving. Aunt Irma, of course, being a nuclear physicist, doesn’t really know that much about Ruby programming in the gravel and sand industry.)
Let the top recruits pick their own project Use cool new technologies unnecessarily
-
Can I identify with the company?
They don’t care about money, actually, unless you’re screwing up on the other things. If you start to hear complaints about salaries where you never heard them before, that’s usually a sign that people aren’t really loving their job. If potential new hires just won’t back down on their demands for outlandish salaries, you’re probably dealing with a case of people who are thinking, “Well, if it’s going to have to suck to go to work, at least I should be getting paid well.”
That doesn’t mean you can underpay people, because they do care about justice, and they will get infuriated if they find out that different people are getting different salaries for the same work, or that everyone in your shop is making 20% less than an otherwise identical shop down the road, and suddenly money will be a big issue. You do have to pay competitively, but all said, of all the things that programmers look at in deciding where to work, as long as the salaries are basically fair, they will be surprisingly low on their list of considerations, and offering high salaries is a surprisingly ineffective tool in overcoming problems like the fact that programmers get 15″ monitors and salespeople yell at them all the time and the job involves making nuclear weapons out of baby seals.
https://www.joelonsoftware.com/2006/09/08/sorting-resumes-2/
The standard job application of cover letter plus resume is a phenomenally weak way to introduce a candidate. They give you only the faintest clues as to the quality of an applicant.
Sometimes, though, a resume gives pretty strong negative clues which allow you to screen out applicants without going much further. Once I got a resume from someone who claimed to be an expert in Microsoft Window [sic] programming. Another time the only experience listed on the application was a job at Dunkin’ Donuts. That resume did a pretty good job of following all the suggestions that high school career-guidance advisors love to give out (this guy “managed trays of donuts”) but there was not a smidgen of evidence that the applicant had ever seen a computer.
Other than that, though, it can be extremely hard to tell much about a candidate from a resume. Our policy at Fog Creek, then, has three parts:
- We try to be selective about how we advertise our jobs, so as to limit the amount of noise in the resume pile.
- We certainly don’t hire based on resumes; we only screen out based on resumes to reduce the number of people whom we have to interview.
- In order to sort the remaining resumes to decide what order to interview people, we use a strictly objective system of reviewing and scoring them, so at least we are being fair and consistent in our interpretation of that very weak signal that comes from resumes.
What to look for:
Passion. Jobs with computers or experience programming going back to a very early age. Extra-curricular activities. Waxing rhapsodic in their cover letter about how they were moved to tears by The Structure and Interpretation of Computer Programs. Sometimes certain programming languages or technologies on a resume indicate evidence of someone who loves programming enough to explore new technologies. At the time I’m writing this, seeing Ruby on a resume is a good sign of the kind of programmer who loves to check out the latest thing and try to improve their skills because they’re passionate about programming, because not so many employers are really demanding Ruby yet.
Pickiness. We look closely at the cover letter for evidence that the applicant really wants to work for us. A bulk-mailed resume can be a symptom of desperation. More importantly, a custom cover letter is a sign that if we do make this candidate an offer, they’re likely to accept it.
English. That said, years of experience working with programmers have taught me that programmers who can communicate their ideas clearly are going to be far, far more effective than programmers who can only really communicate well with the compiler. It is crucial for documenting code, it is crucial for writing specifications and technical design documents that other people can review, and it’s crucial even for those meetings where you sit around discussing how to do something best: brilliant programmers who have trouble explaining their ideas just can’t make as much of a contribution.
Brains. In this category we’re looking for evidence that a candidate is, well, smart, or at least, the kind of nerdy brainiac that went to math camp. Signs of this include high GPAs, high standardized test scores, honors societies like Phi Beta Kappa, people who participate in Top Coder competitions, play competitive chess, or go to ACM Programming contests.
Selectivity. Another thing we look for on resumes is evidence that someone has gone through some highly selective process in the past. Not everyone at Ivy League schools is worth hiring, and not everyone at community college is worth avoiding, but getting into a very selective school does at least mean that someone, somewhere judged you using some kind of selection process and decided that you were pretty smart.
Hard-core. For experienced programmers, there are certain technologies that are considered somewhat more hard-core than others, simply because they are, well, harder to do well. Again, this is a pretty weak indicator, but all else being equal, I’m more impressed by someone who has done work in OCaml than someone who has worked in Java. Assembler or device-driver or kernel work is somewhat more impressive than Visual Basic or PHP. C++ with ATL is harder than Perl. People who have worked on operating systems or compilers are more hard core than people who have worked on simple database front-ends.
Diversity. Someone who has a lot of experience with enterprise software may bring useful diversity to a team of internet programmers. Someone who grew up poor is going to bring useful diversity to a startup full of Andover preppies. A stay-at-home mom rejoining the workplace may bring useful diversity to a team of recent graduates.
If resumes are so weak, can’t we add some other hoops? — No. Great developers have enough choices of places to work that only require the usual cover letter/resume application to get started; by inventing artificial hoops and programming tests and whatnot simply to apply, you’re just as likely to scare away good programmers as weak programmers. Indeed, you may be more likely to scare away the best programmers, who have the most alternatives, and get left with a pool of fairly desperate candidates who are willing to do extra work to apply simply because they don’t have any alternatives.
Don’t look for experience with particular technologies (Don’t start a new project without at least one architect with several years of solid experience in the language, classes, APIs, and platforms you’re building on. If you have a choice of platforms, use the one your team has the most skills with, even if it’s not the trendiest or nominally the most productive. Occasionally, this may mean you interview to find a candidate with really extensive experience in a particular set of technologies (not keywords, mind you: the whole stack, such as LAMP or .NET or J2EE). But most of your software developers should not be hired by keyword matching.)
https://www.joelonsoftware.com/2006/10/24/the-phone-screen-2/
Before moving on to a full-fledged in-person interview, we usually use a phone screen to make sure that we’re not wasting time and money on someone who is just seriously not smart.
The great thing about a phone interview is that it’s much harder to form these kinds of snap judgments; you actually have to listen to what the person is saying and decide if that corresponds to what a smart person might say. This isn’t completely true, of course: you may have prejudices about certain accents or dialects. But at least you are moderately less susceptible to appearance prejudice.
My phone interviews have three parts.
In the first part, I ask the candidate to describe their career history and basically tell me about themselves. This is mainly intended to get them loosened up and feeling comfortable, to eliminate any nervousness, and to let them sort of present themselves the way they want to be presented. During this stage, you should be looking for evidence that the candidate is a problem solver: the kind of person who gets things done. You’re also looking for passion. You want people who care about the stuff that they did.
During this part I’ll drill down on two kinds of things: technology and politics.
-
Technology. If someone tells me that they implemented such-and-such a project, I’ll ask detailed questions about the technology they used and how they used it. I’ll also ask specifically what role they played. Sole developer? Developer on a team? I’ll tend to go into these questions in great detail, because this is where you uncover the people who either didn’t know what they were doing, or have made things up, or have exaggerated their own roles. If someone’s resume implies that they spent two years coding in Python, for example, I’m going to drill down until I’m pretty confident that it sounds like they really have two years of Python experience.
Don’t hesitate to use trick questions. I might say, “I hate Python, because it’s really tedious to declare all your variables. That’s why I like C better.” Python doesn’t make you declare variables (and C does). Don’t be afraid that the candidate will feel pressured to agree with your false assertion. Smart programmers have a certain affinity for the truth, and they’ll call you on it. As Dave Winer says, “You can’t lie to a compiler.” If they’re really good, they’ll find a way to be diplomatic about it. But they’re going to be passionate enough that they’ll almost forget that they’re in an interview. That’s a good sign.
-
Politics. Behind the boring list of past employers on the resume, there’s always a story. What I’m looking for is the story of how the candidate handled challenges in the past. I’m looking for people that got things done, even in the face of opposition. I’m looking for people who challenged the status quo, who overcame objections, and who made things happen. So when the resume says, “drove the adoption of .NET,” I want to hear what drove means. In detail. When the resume says that they “founded a company,” I want to hear everything. Whose idea was it? Who convinced whom? Who did what? Did it work out? Why not?
The second part of the phone screen is the technical problem. I usually ask the same question for years and years before switching it, because this makes it easier to compare candidates. The question is a wide-ranging, open design question: how would you design a data structure or a block of code to do x? Where x is something kind of big and complicated. I usually have a series of questions ready to guide the candidate down a particular path in the design of this data structure or block of code, because it’s such a big question, and I can often tell how smart the candidate is by how far they get down that path in a fixed amount of time.
Here are some ideas to get you started:
- How might you design a program that lets people play Monopoly with each other over the internet?
- What would be a good data structure for a photo editor?
- How would you implement code to operate the elevators in a high rise?
- How would you implement the rendering engine of a web browser?
The ideal question takes something where the interviewee is deeply familiar with how the thing works from having used it, but is unlikely to have ever implemented it themselves. You want something that can be done over the phone, without too much writing, so “how would you write the code for quicksort” is a bad question, because we don’t expect programmers to be able to recite code over the phone. You want to have a conversation about algorithms and data structures, really, the meat and potatoes of programming, where the goal is not to find the best possible answer, necessarily, but simply to give you the opportunity to talk about code, to talk about time/space tradeoffs, to talk about performance characteristics of code, all of which will add up to giving you a pretty good idea in your mind whether the person you’re talking to is actually pretty good at programming and whether they’re smart or not.
The bottom line in my interviewing technique is that smart people can generally tell if they’re talking to other smart people by having a conversation with them on a difficult or highly technical subject, and the interview question is really just a pretext to have a conversation on a difficult subject so that the interviewer’s judgment can form an opinion on whether this is a smart person or not.
The third and final part of the interview is letting the candidate interview me. Remember, the whole philosophy of recruiting is predicated on the idea that smart candidates have a choice of where to work, and if that’s true, the interview process is as much a way for the candidate to decide if they want to work for us as it is a way for us to decide if we want to hire the candidate. “Do you have any questions about Fog Creek, about working at Fog Creek, or anything else you want to ask me?”
Sometimes this part of the interview reveals a frightening lack of preparation by the candidate. “So, what exactly does Fog Creek do? And where are you located?” Failing to do even the most basic homework before the interview, by spending five minutes on our web site, does not give me a great deal of confidence in the candidate’s ability to be smart or to get things done.
By this point I’ve already decided if this person seems smart enough to score an in-person interview. So I treat the third part of the phone interview as if I were the one being interviewed, and the candidate was the one that had to be sold on Fog Creek. Which they do.
https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guide-to-interviewing-version-30/
You should always try to have at least six people interview each candidate that gets hired, including at least five who would be peers of that candidate (that is, other programmers, not managers). You know the kind of company that just has some salty old manager interview each candidate, and that decision is the only one that matters? These companies don’t have very good people working there. It’s too easy to fake out one interview, especially when a non-programmer interviews a programmer.
If even two of the six interviewers thinks that a person is not worth hiring, don’t hire them.
Don’t try to interview a bunch of people at the same time. It’s just not fair. Each interview should consist of one interviewer and one interviewee, in a room with a door that closes and a whiteboard. I can tell you from extensive experience that if you spend less than one hour on an interview you’re not going to be able to make a decision.
You’re going to see three types of people in your interviews. At one end of the scale, there are the unwashed masses, lacking even the most basic skills for this job. They are easy to ferret out and eliminate, often just by asking two or three quick questions. At the other extreme you’ve got your brilliant superstars who write lisp compilers for fun, in a weekend, in Assembler for the Nintendo DS. And in the middle, you have a large number of “maybes” who seem like they might just be able to contribute something. The trick is telling the difference between the superstars and the maybes, because the secret is that you don’t want to hire any of the maybes. Ever.
At the end of the interview, you must be prepared to make a sharp decision about the candidate. There are only two possible outcomes to this decision: Hire or No Hire. There is no other possible answer. Never say, “Hire, but not for my team.” This is rude and implies that the candidate is not smart enough to work with you, but maybe he’s smart enough for those losers over in that other team. If you find yourself tempted to say “Hire, but not in my team,” simply translate that mechanically to “No Hire” and you’ll be OK. Even if you have a candidate that would be brilliant at doing your particular task, but wouldn’t be very good in another team, that’s a No Hire. In software, things change so often and so rapidly that you need people that can succeed at just about any programming task that you throw at them. If for some reason you find an idiot savant that is really, really, really good at SQL but completely incapable of ever learning any other topic, No Hire. You’ll solve some short term pain in exchange for a lot of long term pain.
Never say “Maybe, I can’t tell.” If you can’t tell, that means No Hire. It’s really easier than you’d think. Can’t tell? Just say no! If you are on the fence, that means No Hire. Never say, “Well, Hire, I guess, but I’m a little bit concerned about…” That’s a No Hire as well. Mechanically translate all the waffling to “no” and you’ll be all right.
Why am I so hardnosed about this? It’s because it is much, much better to reject a good candidate than to accept a bad candidate. A bad candidate will cost a lot of money and effort and waste other people’s time fixing all their bugs. Firing someone you hired by mistake can take months and be nightmarishly difficult, especially if they decide to be litigious about it. In some situations it may be completely impossible to fire anyone.
In principle, it’s simple. You’re looking for people who are
- Smart, and
- Get things done.
That’s it. That’s all you’re looking for. Memorize that. Recite it to yourself before you go to bed every night. You don’t have enough time to figure out much more in a short interview, so don’t waste time trying to figure out whether the candidate might be pleasant to be stuck in an airport with, or whether they really know ATL and COM programming or if they’re just faking it.
The second worst kind of interviewer is the Quiz Show Interviewer. This is the kind of person who thinks that smart means “knows a lot of facts.” They just ask a bunch of trivia questions about programming and give points for correct answers. Just for fun, here is the worst interview question on Earth: “What’s the difference between varchar and varchar2 in Oracle 8i?” This is a terrible question. There is no possible, imaginable correlation between people that know that particular piece of trivia and people that you want to hire. Who cares what the difference is? You can find out online in about fifteen seconds!
But in general, the way to learn the most about a person is to let them do the talking. Give them open-ended questions and problems.
Before the interview, I read over the candidates resume and jot down an interview plan on a scrap of paper. That’s just a list of questions that I want to ask. Here’s a typical plan for interviewing a programmer:
- Introduction
- Question about recent project candidate worked on
- Easy Programming Question
- Pointer/Recursion Question
- Are you satisfied?
- Do you have any questions?
A lot of programmers that you might interview these days are apt to consider recursion, pointers, and even data structures to be a silly implementation detail which has been abstracted away by today’s many happy programming languages. “When was the last time you had to write a sorting algorithm?” they snicker.
Still, I don’t really care. I want my ER doctor to understand anatomy, even if all she has to do is put the computerized defibrillator nodes on my chest and push the big red button, and I want programmers to know programming down to the CPU level, even if Ruby on Rails does read your mind and build a complete Web 2.0 social collaborative networking site for you with three clicks of the mouse.
Inevitably, you will see a bug in their function. So we come to question five from my interview plan: “Are you satisfied with that code?” You may want to ask, “OK, so where’s the bug?” The quintessential Open Ended Question From Hell. All programmers make mistakes, there’s nothing wrong with that, they just have to be able to find them. With string functions in C, most college kids forget to null-terminate the new string. With almost any function, they are likely to have off-by-one errors. They will forget semicolons sometimes. Their function won’t work correctly on 0 length strings, or it will GPF if malloc fails… Very, very rarely, you will find a candidate that doesn’t have any bugs the first time. In this case, this question is even more fun. When you say, “There’s a bug in that code,” they will review their code carefully, and then you get to see if they can be diplomatic yet firm in asserting that the code is perfect.
I always leave about five minutes at the end of the interview to sell the candidate on the company and the job. This is actually important even if you are not going to hire them. If you’ve been lucky enough to find a really good candidate, you want to do everything you can at this point to make sure that they want to come work for you. Even if they are a bad candidate, you want them to like your company and go away with a positive impression.
In the past, I’ve used “impossible questions,” also known as “back of the envelope questions.” Classic examples of this are “How many piano tuners are there in Seattle?” The candidate won’t know the answer, but smart candidates won’t give up and they’ll be happy to try and estimate a reasonable number for you. Let’s see, there are probably… what, a million people in Seattle? And maybe 1% of them have pianos? And a piano needs to be tuned every couple of years? And it takes 35 minutes to tune one? All wrong, of course, but at least they’re attacking the problem. The only reason to ask a question like this is that it lets you have a conversation with the candidate. “OK, 35 minutes, but what about travel time between pianos?”
“Good point. If the piano tuner could take reservations well in advance they could probably set up their schedule to minimize travel time. You know, do all the pianos in Redmond on Monday rather than going back and forth across 520 three times a day.”
A good back-of-the-envelope question allows you to have a conversation with the candidate that helps you form an opinion about whether they are smart. A bad “Aha!” pirate question usually results in the candidate just sort of staring at you for a while and then saying they’re stuck.
The optimal time to make a decision about the candidate is about three minutes after the end of the interview. Far too many companies allow interviewers to wait days or weeks before turning in their feedback. Unfortunately, the more time that passes, the less you’ll remember.
If you’re having trouble deciding, there’s a very simple solution. NO HIRE. Just don’t hire people that you aren’t sure about. This is a little nerve wracking the first few times—what if we never find someone good? That’s OK. If your resume and phone-screening process is working, you’ll probably have about 20% hires in the live interview. And when you find the smart, gets-things-done candidate, you’ll know it. If you’re not thrilled with someone, move on.
https://www.joelonsoftware.com/2005/07/25/hitting-the-high-notes/
For today, though, I want to answer just one question, because if this part isn’t true, the whole theory falls apart. That question is, does it even make sense to talk about having the “best programmers?” Is there so much variation between programmers that this even matters?
Here’s why: duplication of software is free. That means that the cost of programmers is spread out over all the copies of the software you sell. With software, you can improve quality without adding to the incremental cost of each unit sold.
Essentially, design adds value faster than it adds cost.
If the only difference between programmers were productivity, you might think that you could substitute five mediocre programmers for one really good programmer. That obviously doesn’t work. Brooks’ Law, “adding manpower to a late software project makes it later,” is why. A single good programmer working on a single task has no coordination or communication overhead. Five programmers working on the same task must coordinate and communicate. That takes a lot of time. There are added benefits to using the smallest team possible; the man-month really is mythical.
The real trouble with using a lot of mediocre programmers instead of a couple of good ones is that no matter how long they work, they never produce something as good as what the great programmers can produce.
Five Antonio Salieris won’t produce Mozart’s Requiem. Ever. Not if they work for 100 years.
Five Jim Davis’s — creator of that unfunny cartoon cat, where 20% of the jokes are about how Monday sucks and the rest are about how much the cat likes lasagna (and those are the punchlines!) … five Jim Davis’s could spend the rest of their lives writing comedy and never, ever produce the Soup Nazi episode of Seinfeld.
The Creative Zen team could spend years refining their ugly iPod knockoffs and never produce as beautiful, satisfying, and elegant a player as the Apple iPod. And they’re not going to make a dent in Apple’s market share because the magical design talent is just not there. They don’t have it.
You can’t afford to be number two, or to have a “good enough” product. It has to be remarkably good, by which I mean, so good that people remark about it. The lagniappe that you get from the really, really, really talented software developers is your only hope for remarkableness. It’s all in the plan:
Best Working Conditions → Best Programmers → Best Software → Profit!