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

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!!!!

[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.