rebootied

Joel Spolsky is, to put not too fine a point on it, a fucking moron. Like most people who claim to be in software, but spend more time writing about it than actually doing it.

Hiring superstars is a terrible idea. What it gets you is a lot of arguing and bitching and people trying to write the Perfect Code, when Good Enough will carry the day. What you need is one superstar per functional team, whom you install as the architect, and then have them managed by either an ex-Superstar or a promoted project manager. Under them, you have nice people who are smart but not geniuses, and who will work very hard implementing said architecture.

How many man-hours are wasted reviewing 400 candidates for every hire? There simply isn't that much differentiation between candidates, even at the top levels. Review fifty, tops. Hire one. And that's for the top jobs. For the rest, you want people who are interchangeable, because staff turnover is going to be high -- higher, even, when you're hiring TEH SOOPERSTARZ.

Second, fine-grained time estimates have been discarded as a workable theory since the early 90s. What you want is a reasonable range of delivery times, which get more and more fine-grained as the product goes forward. Saying, "I can deliver a product on Sept. 30th!" when said product depends on the work of 10-20 people, any of whom may get sick, may quit, may take a vacation, whatever, is retarded.

"The answer is get more resources" is perhaps the dumbest thing in the whole article. Building a product is not Amish barn-raising. More does not equal better. If your schedule is off, you either re-negotiate the schedule, or you drop features. End of story. And if you've taken the yardstick approach ("we'll deliver between August 5th and September 15th"), then slippage on the scale he's talking demonstrates that your SOOPERSTAR leaders are idiots.

Anyone who is tempted to reassign work is stupid. If you need to reassign work, it should only be when you've replaced a person in the organization.

The only thing he says that isn't stark-raving mad is that people should work 40 hours a week. But I take it a step further -- as long as people are meeting their project deadlines, they should work as long as they've comfortable. I've had people work 20 hours a week and produce as much as people working 60. And I've had people who didn't want to be forced to work only 40 hours -- they enjoyed their jobs, so worked 80 quite happily.

To summarize -- Spolsky is an idiot. He's the kind of idiot that people who have "How To Manage People" books on their desks just love to quote. I mean, dude -- this is the guy who gave us Excel and Visual Basic. How bright can he be?

From:

Y'know, that whole comment came off as much more acerbic than I intended. I was kinda frothing at the silliness Spolsky was espousing. Please pardon my venom -- I became aware after posting that you were, in fact, quoting Spolsky, which means I indirectly called you stupid. And also...for all I know, he's a friend of yours, which means I may have just insulted your friend.

Mea culpa. I could've written that with a little less invective, and still gotten my points across.

From:

I don't know. I read Spolsky's quote and got kind of riled up about it too. The single thought going through my head was "Has this guy ever actually directly managed a development team? It's not so black and white."

I found myself agreeing with your points, invective and all, 100%.

From:

Thanks for that. I still think I could've been a little less harsh and managed to make the same points...but I don't feel like so much of a gonad now. So thank you.

From:

Don't worry! You're still a gonad! :-)

From:

Your words burn and sting! Aieee!

From:

LLOOLLz0r.

From:

Nope. No gonads here.

Oh wait, that didn't come out right.

What I really meant was^H^H^H^H ....CONNECTION TERMINATED.

From:

You're not a fan?

From:

Some of the things he said seem spot on, but other points are a bit out of touch with reality.

Things I agree with:
* encourage staff to put in 40 hours. Encourage them to get sleep. I've seen lots of guys put in that extra bit of effort to roll out a project and get themselves burnt out by it or worse produce shit code due to the pressure. The damaging effect on productivity and morale just isn't worth it. However, to get past that problem you really need to have project managers set up realistic project schedules. If it's going to take 2 days to code, don't assign 6 hours. I understand the need to please the client and stay competitive but if you hand the client a half-working buggy product, they won't be pleased.

* If you can't release on-time, renegotiate the schedule or cut features. I'm not sure what more resources you can throw at the project, Spolsky even admits that it takes time for a new person to come up to speed on a project. In my experience, assigning more cooks to the stew slows things down.

Things I don't think he's correct on:
* "fine-grained estimates from developers" and "creating reliable project blueprints". It doesn't sound like he knows what he wants. You aren't going to get anything reliable if you ask your developers-- who've never built the solution before --to give a fine-grained time estimate on how long it will take to build something. Once you finish the project, you could *then* have your blueprint, but then who builds the same solution over and over again?

What I think he should've said was, "ask your developers for a fine-grained plan on how they will build the solution". That's what we ask developers for at my company and I like it personally. It causes the developer to really sit down and think out the problem and all the possible issues before they start coding. Other companies I've worked for would require an overview doc or something to give QA a feel for how to test, but I think a tech spec that's as fine-grained as possible is better. However, I'm not asking for time estimates.

* As others have pointed out, it's better to have a group of mid-level, ego-less, guys than one superstar who then proceeds to demoralize the rest of the team. A development team works best when it's a team and not a competition. A team of competent, but not spectacular, guys/gals who get along and can motivate each other is truly a thing of beauty in the code world and is not to be off-balanced with the addition of an overwhelming ego.

IMHO, if you want to hire superstars, you should constrain them to high-level architecture, but not development, positions or hire super-star project managers. People who can think through and manage large problems/projects are far, far more valuable than people who can write a fractal engine in one line of perl code. Superstars are expensive and part of the cost is to maintain the hype, and the sooner software firms figure that out, the better off they will be.

And wtf is with Spolsky and interviewing 400 people? I admit I've interviewed my fair share of losers, but the sheer time/money you waste sifting through 400 candidates is better spent on your project. Unless you also have an army of HR people to help split this up, I can't understand the point of it. Here I thought after reviewing about 20 candidates that we were being picky. :)

From:

And wtf is with Spolsky and interviewing 400 people?

Just to be clear:
At Fog Creek, we tend to review about 400 candidates for every full-time hire - emphasis mine; it's not surprising that they get a mess of résumés and that most of them are sheeit or sheeeit-like; I suspect out of those 400, he probably interview 10 people.

From:

Ah yeah. That does make it seem a bit less mind-boggling overkill. Point taken.

From:

Just a few points, to start off with:
I don't think Spolsky cares if someone wants to work an 80 hour week; he more likely is talking about the stupid, degenerative, counterproductive corporate cultures which blithely mandate that you're in there for a 50 or 60 hour week as a normal operating procedure. Sure, some people get into their work, and can do it for long stretches. In particular when a programmer hits their flow-state, it seems like it's not just a job but a frame of mind that has a nearly perpetual-motion like state, so long as the Mountain Dew / Red Bull / Indonesian Double-Caffeine Rocket Espresso Roast holds out.

FWIW, in terms of most dev teams, I agree with your assessment of hiring a lead architect who is a fooking jeenyus and then some good people who will be inspired by the jeenyus and beat their asses to keep up with the jeenyus's level of implementation.

Scheduling -- I'll have to think more about that.

From:

super-nyanko.livejournal.com

You know, if Joe Blow is The One Mister Super Fabu Desirable Developer that Spolsky has been looking for, he'd be long hired by another company by the time Spolsky is done with his 399 other interviews.

And frankly, I think you can tell good from bad in most interviews but can you tell super from great? I don't think so. I think some people are great selling themselves but that doesn't make them The Bestest Ever at their jobs.

And I've been on teams where people have had work taken away from them and given to someone else because they weren't doing it fast enough. It happens. Does that mean they should be fired? I honestly don't know. There are always junior people on a team, there are always senior people that clean up after them. I have rarely been on a team without junior people and you need to have them to replace all the senior people who will burn out soon enough :)

From: