Better Development Through Competition?

theodp writes "Among the tips Derek Sivers offers for how to hire a programmer to make your ideas happen is an intriguing one: hire more than one person to complete your first programming milestone, with the expectation that one will go bad, one will be so-so, and one will be great. 'Yes it means you're paying multiple times for this first milestone,' says Sivers, 'but it's worth it to find a good one.' It's not a new idea — the practice of pitting two different programmers against each other on the same task was noted three decades ago in Tracy Kidder's Soul of a New Machine — but one that never gained widespread acceptance. Should the programming code-off be adopted as a software development best practice?"

Comments

Companies don't know

[Herkum01]

The fact is companies like to treat most jobs, excluding management positions, as unskilled labor. Not unskilled as in 7-11 but as one programmer is the same as any other programmer. This does not apply just to programmers but a large range of positions.

So even though you maybe the best of the group in your company, they will not care because they are not willing to expend the energy to find out. You are all the same as far as they are concerned.

Re:Companies don't know

[khallow]

The fact is companies like to treat most jobs, excluding management positions, as unskilled labor.

The fact is people make generalizations.

Re:Companies don't know

[wonkavader]

The word you want is "fungible" -- one programmer is exactly the same as any other. You can swap 'em around and get the same result.

This worked when you hired 7 year olds to run machines in the 1800's, and since those were the glory days for employers, they keep thinking that way.

Re:Companies don't know

[deuterium]

Exactly. My brother, who works for a Dow 30 company, said that during a company seminar on HR, the speaker made an analogy regarding an individual's role in the organization. He asked them to think of putting their hand in a bucket of water, and then withdrawing it, then asked "how fast does the water replace your hand when you take it out?" Instantly. "That's how quickly you can be replaced."

They don't care if you're exceptional, only that you're adequate, because it's a lot of work to identify exceptional workers and there aren't many of them. Unless you're the CEO or a VP, you're not setting policies, you're only following them, so followers are needed.

Practicality

[Voulnet]

Usually a stunt like that lacks lots of real world practicality. Software development is a delicate craft, and it requires patience and attention to detail. It's difficult to attain that by pitting two programmers against each other. You can be certain of bugs, memory leaks and security vulnerabilities for example. Besides, won't it damage cooperation and teamwork? Your competition should be with the competing companies in the market, not a civil war within.

Re:Practicality

[hoggoth]

Contract rates? Where have you been the last 10 years. Contract rates start at 10 rupees.

Re:Practicality

[zippthorne]

Ahh, the "Survivor" model of programming.

Far better, I think, would be to hire the programmers you can afford, and if possible divide into competing groups for the first milestone, at which point, you pick the better idea, divide into new groups, and set those groups to work on the next milestone.

You can't run a business like a game show for very long without burning everyone out.

Wrong expectations

[Chemisor]

I'd say that when you hire three programmers, it is more appropriate to expect that one of them will be bad, the second one will be bad, and the third one will be the worst of all.

Re:Wrong expectations

[DoofusOfDeath]

Good call. They should hire four programmers!

Re:Wrong expectations

[Noughmad]

Good call. They should hire four programmers!

Why not up it to eleven?

First will sadly win

[notthepainter]

Not best, but first will win. That's my guess based on how most industries work.

Interesting idea, but...

[Anonymous Coward]

I find the idea intriguing, and I'm just prideful enough to think that -my- work would be the one chosen, but...

What if it isn't? I will have spent days, weeks or months working for a company that doesn't want me around any more. I won't have any other job prospects lined up, and I'm just back where I am, but now with either a big hole in my employment or a -very- short job on my employment list. It seems to me that this is a massive gamble.

Also, how does the company judge which is best? There are so many factors involved in such a determination, and many of them aren't something that a non-programmer can even understand, let alone quantify.

Code Readability
Comment usefulness
Self-documenting code
Documenation usefulness
Speed
Unit Testing Coverage
Unit Testing Usefulness

Those are just right off the top of my head on how I'd judge the work, but non-programmers couldn't judge most of them. So you have to already -have- an excellent programmer to do the judging, and you have to get one who isn't afraid of the new guy taking his job.

So on top of the gamble on whether you are the best programmer, you also have to gamble that the company can judge the work properly as well.

No thanks.

On the other hand, if you are outsourcing, this makes a lot more sense. Give the project to 3 companies and let them fight it out, and have an in-house developer (the one who is going to liaison for the project anyhow) do the judging. The outsource companies are better off because they had some work and they aren't screwed out of their next job by this one.

Code Competition may not always work!!!!

[flajann]

I was once involved in a project where this sort of thing was going on, and those that had the better looking GUI got the nod. I focused more on the infrastructure and the middleware, knowing I could pretty up the GUI later. The competition only focused on the GUI exclusively, but no infrastructure. Theirs looked much prettier than mine. They got the nod, and I simply walked.

Competitive programming, if not done right, can actually make matters worse rather than better. My GUI always looks like crap until near the end of the project, after I get all the infrastructure in place, working, and stable. I don't like focusing on the GUI up front because their are usually many requirement changes and what not and would have to be redone anyway. Better to wait until a later stage when everyone has had a chance to think about what they really want.

Alas, other departments, project managers, and what not only see the GUI and have no clue about what it takes to support the GUI underneath. The GUI is just the tip of the iceberg. It's the least important as far as overall functionality, but it's what everyone sees and reacts to. The database schema, the middleware, the messaging protocols, stuff you have to design in to make it scalable, robust, and secure -- all of that is "under the hood". Neglect it to your own peril.

Re:Code Competition may not always work!!!!

[OneMadMuppet]

I disagree with one significant thing: the UI is at least as important as the DB, middleware and protocols, precisely because it's what everyone sees and reacts to. I've used some very well architected software be absolute pigs to use because people thought the UI wasn't important. If it's going to be used every day, it should be simple, intuitive and look good. If it's going to be used by non-engineers it's even more important. As anyone who's ever tried to design a good UI knows - simple and intuitive are hard for anything past Hello World. Believing that you can just slap any GUI at all onto a well-engineered piece of software is wrong (I'm looking at you IBM and Sun) and is the equivalent of saying you can throw together a pretty website in 30 mins using notepad.

Re:Code Competition may not always work!!!!

[coryking]

This is horrible advice! Your method is why we have such shitty software and is why companies like Apple are stealing Microsoft's lunch! Yes the backend is important and you shouldn't neglect it, but the GUI is what drives the design of the backend! It is, in essence, the high-level requirements document for the entire application stack! If you don't have the GUI design, how the hell do you even know what the bowels of the application should be doing!?

It's the least important as far as overall functionality, but it's what everyone sees and reacts to.

The GUI is the most important because as you say, it the part that actually gets touched by non-programmers. The UI should drive the design of everything below it--including the database schema , the middleware, and things like the messaging protocols.

I don't like focusing on the GUI up front because their are usually many requirement changes and what not and would have to be redone anyway. Better to wait until a later stage when everyone has had a chance to think about what they really want.

You *should* do the GUI up front because the GUI dictates the design of the entire system. You don't have to make it hi-fidelity (i.e. functional)--you can get away with simple things like Paper Prototypes*. Let the design process be iterative and don't be afraid to throw bad ideas (literally). Paper is cheap, development time is not!

Alas, other departments, project managers, and what not only see the GUI and have no clue about what it takes to support the GUI underneath. The GUI is just the tip of the iceberg.

This is true, and is the exact reason you should nail down the GUI first. How they use it is all they care about, and is the exact reason why you should nail down those requirements before you do anything to your backend. They aren't gonna come bitching to you about how your databases lack some index, but they might complain that your list of videos isn't dropping stop words like "The" or "A". A change to how the list sorts could well affect the entire application stack. Do you want to know about that before or after you finished your backed?

If you do the backend before the front end, your backend will wind up driving the functionality of the GUI instead of your customer. In other words, if you do the GUI at the end, you've invested so much time into the backend it becomes very costly to make changes to the GUI that would necessitate fundamental changes to the backend.

Bottom line, your method is fundamentally wrong. Let the design of UI drive the backend, not the other way around.

* Some people do their mockups in visio or photoshop but I'm personally not a fan as it allows you to make an interface look too real and thus people focus on the colors and fonts when all you are after is the overall grid and the flow of different screens/pages. Worse, your customer might think you are closer to being finished then you actually are (after all, your prototype looked so good that we assumed it just needed the buttons wired in!) Worse still, doing it in visio or photoshop takes more time and the idea of initial prototypes is that you dont invest much time in them so you don't feel bad about throwing bad ideas away. Personally I dont even commit to ink when doing my initial designs, I do it in pencil and when I really like something I trace it over with a permanent marker.

Re:Code Competition may not always work!!!!

[coryking]

You need to develop the low-level stuff first, and do so well and solidly.

What parts you *develop* first dont matter so much as you *design* your user interface first. Note I did *not* suggest you go jumping into *programming* the GUI first. Instead I advocated you *design* the GUI *before* you write a single line of code.

I mean, it is common sense! How the hell do you know what you should be programming before you know how the damn application should work!?

If someone isn't skilled enough to compare...

[Anonymous Coward]

If someone isn't skilled enough to compare the quality of two programmers and select the best one for their project, what makes them think they are skilled enough to compare/judge the quality of two programmer's work?

This seems to be a recipe for premature optimisation and poorly maintainable code. It might get you a good first milestone, but it might be screw you in the long run.

Sweat Shop?

[drooling-dog]

As an employer I'd like the idea a lot. As a programmer, though, this would quickly lead to intolerable working conditions. Are the other "candidates" willing to work 16-hour days in order to win the job permanently? Then, unless I'm a lot more efficient than the best of them, so will I. Then, once the initial milestone has been reached, I will have created expectations that would be impossible to satisfy in the long run. I'd have to be fairly desperate to put myself in a situation like that.

Not at all

[gweihir]

There are multiple problems with this approach. One is that you cannot easily evaluate code quality. The important characteristics will show only over time or if you have somebody very experienced invest a lot of time into the evaluation. A second one is that you cannot know whether the best person until the first milestone does actually know how to pace him/herself. It is well possible to have somebody come in best that later burns out. At the same time it is well possible to have somebody that actually would do reasonably well for the whole project duration, not do best until the first milestone. This could be prevented bu allocation generous resources for the first step, but it seems very likely that nobody is going to do that, and even more likely that resources will be far too low to save some of the triple effort.

My take is that this is another stupidity by people that do not understand software creation. This is doomed to fail. Personally I would refuse to participate.

Christ, what a moron

[0xdeadbeef]

Doesn't this guy sound like every drunk imbecile who, upon finding out you write software, wants to sell you on how he's got this great idea for the next Facebook or Apple or eBay? For the percent of a percent of them who act on their delusions, they are the ones you see ridiculed on the Internet for ridiculous job postings.

These people have a conception of software development derived from 24, and have the intelligence necessary to remain that ignorant.

But do you know what's most funny? He betrays the shibboleth of every incompetent business person, and assumes the same of his audience: he thinks he is an expert in user interface design. "Write a detailed walk-through of every click." When you see any spec like that, withhold your laughter, and decline whatever they are offering.