Better Development Through Competition? 251
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?"
Re:Practicality (Score:3, Interesting)
I agree that you want to have your team working together. But what about the idea of "come up with you you think this should work". By coming at it from different perspectives there are more possibilities to come up with something interesting.
Ideally you could blend the best ideas from both. That said, in many ways this isn't practical from today's business perspective, where resources are so thin, that you can barely get one fully staffed team.
Re:Practicality (Score:3, Interesting)
This scenario refers specifically to hiring freelance programmers to complete a project. You want one programmer (or small team) so you hire several to do the first milestone and then keep the one which works best.
Yeah, the summary could have been better.
Re:Maintainability (Score:2, Interesting)
It's not enough to take into account quality of the finished product as such. You also have to take into account how maintainable it is and how easily it can be modified for future requirements. That's one of the thoughest parts of software development and that takes years to learn and is easily overseen by clueless management.
Re:Practicality (Score:3, Interesting)
Re:Companies don't know (Score:5, Interesting)
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:Wrong expectations (Score:3, Interesting)
Good call. They should hire four programmers!
Why not up it to eleven?
Re:Practicality (Score:5, Interesting)
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.
Re:Companies don't know (Score:3, Interesting)
That's often true, but there's also another common reason: The managers of software projects often don't have a clue about how to judge the "value" of a piece of software. This can be true even for managers who used to be programmers, if the tools (languages, libraries, etc.) are different that what they were trained on.
You can see symptoms of this in a lot of companies that try to measure their software. It's how you get such things as "lines of code" as a measure of programmer productivity. It's hard to think of a more counter-productive way to quantify software, but it's what you get when there's an official demand for metrics for quantities that nobody knows how to measure.
Re:Code Competition may not always work!!!! (Score:1, Interesting)
Bad news, dude. You won't ever know how the application should work early on. It will be revised continually, even after it ships, if it's anything of value.
You want the low-level stuff to be flexible and scalable enough to handle things efficiently, no matter how the front end changes.
With your approach, that the front-end drives the back-end, you'll end up changing both every time there's a change to the front-end. It should be obvious that this is inefficient, and consequently, poor engineering.