Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Better Development Through Competition?

Soulskill posted more than 3 years ago | from the there-can-be-only-one dept.

Programming 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?"

cancel ×

251 comments

Sorry! There are no comments related to the filter you selected.

My first employment (2, Funny)

Z00L00K (682162) | more than 3 years ago | (#32631604)

My first employment was handled that way.

Re:My first employment (1, Funny)

Anonymous Coward | more than 3 years ago | (#32631630)

And quickly led to your first unemployment?

Re:My first employment (0)

Anonymous Coward | more than 3 years ago | (#32631666)

No, he's so-so, but had a gook work ethic, so he works in the IT department now.

Re:My first employment (1, Funny)

Anonymous Coward | more than 3 years ago | (#32631802)

correction, he is the CEO now.

Metrics (0)

Anonymous Coward | more than 3 years ago | (#32631610)

With some seriously exact metrics this can work.

Not just speed but code quality, test coverage etc. it is viable

unfortunately measuring this impartially can be a pain

There is only one reliable software meric. (0)

Anonymous Coward | more than 3 years ago | (#32631658)

You ask, "Was this software developed by Indians?"

If the answer is "yes", then it is shitty software.

Re:There is only one reliable software meric. (1)

Rivalz (1431453) | more than 3 years ago | (#32631734)

Usually when I do work it is for the whole project.
There are people out there who are willing to be jerked around with a 33% of being hired to complete a full project?

You know what I would do is sub out a few people to help me with the first milestone and then just sub out to one dumb ass to complete the rest of the project.

Re:Metrics (1)

obarthelemy (160321) | more than 3 years ago | (#32631900)

I used to be the first-line filter for my (small, 2 or 3 interviews got you in, after me you moved on to CEO then CTO) tech company's recruitment. On of the things we did was ask people to clone a 4-ops desktop calculator. Which was a trick, devs had to work out for themselves that they had to handle priorities and /0. About 60% of people failed at one or both, and that rose lotsa flags with us about the required level of hand-holding.

Re:Metrics (1, Insightful)

Anonymous Coward | more than 3 years ago | (#32632452)

priorities? If you mean operator precedence, then, a simple 4-ops calculator will not (and arguably should not) handle that.

Type in 2+5*4 on a calculator. Most calculators will return 28. Only math calculators will return 22.

Companies don't know (4, Insightful)

Herkum01 (592704) | more than 3 years ago | (#32631624)

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 (1)

LarrySDonald (1172757) | more than 3 years ago | (#32631670)

This is often true in large corporations, but many smaller companies devote much more time to figuring out who is best for what and who is so bad that they shouldn't be there. This is what's known as "management" which is also a skill. The problem is that there aren't that many skilled managers because it's really hard and it only gets harder in middle and upper management (i.e. figuring out who would be good at figuring out who should do what). There are good managers, but they usually got rich and now run small/medium companies more for laughs.

Re:Companies don't know (1)

SirRedTooth (1785808) | more than 3 years ago | (#32631672)

Only if the company doesn't happen to be a tech company.

Re:Companies don't know (3, Insightful)

khallow (566160) | more than 3 years ago | (#32631794)

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 (2, Insightful)

tomhath (637240) | more than 3 years ago | (#32631970)

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

You seem to imply that "managers" somehow spring forth from nothingness to become these godlike creatures. Most places I've worked the managers were once doing the job they are now managing. The exception is when the general manager is promoted up from Sales & Marketing; soon all the other managers are burned out salesmen who have no clue how to manage a project other than set goals and give frequent pep talks.

But back to the original topic, this seems like a bad idea to me. First (as has already been mentioned) the winner will be the person who is best able to sell his/her implementation, this usually means they either went for the "sizzle and not the steak", or they are in bed with the person making the decision. Second, you're unlikely to get a really good, professional programmer to work in that environment; they'll just go someplace else where the development organization is better organized.

Re:Companies don't know (1, Redundant)

hedwards (940851) | more than 3 years ago | (#32632096)

And the job I just quit was being managed by a jack ass with neither managerial nor industry experience. He was literally hired so that his boss wouldn't have to worry about competing with him for his job in the future. It's something which is richly rewarded in the US. Screw things up via incompetence and you'll almost certainly get bought up. With all the executives getting a golden parachute while massive layoffs for redundancy affect the people actually doing the work.

Sucks, but that's what you get for working in a nation with one of the least free markets in the free world.

Re:Spring (1)

TaoPhoenix (980487) | more than 3 years ago | (#32632258)

Not always. The ones who Were There are the ones I respect. But there really is a serious problem first nationally trumpted by Dilbert, that "managers" DO "spring forth from nowhere" because they're good at the old high school Let's Make a Clique games. Getting rid of those guys is a pain because they outrank you, and usually too savvy to do anything truly stupid. Rather, they specialize in doing Vague Nothings.

Re:Companies don't know (4, Interesting)

wonkavader (605434) | more than 3 years ago | (#32632002)

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 (1)

noidentity (188756) | more than 3 years ago | (#32632066)

And companies aim to be stable over the long run, not dependent on any particular employee's special skills. When I write a program, I try to make it as portable as possible, not depending on any special features unless they give a big benefit and outweigh the dependency and inflexibility involved. Maybe some of this applies to running a company.

Practicality (4, Insightful)

Voulnet (1630793) | more than 3 years ago | (#32631632)

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 (2, Interesting)

h2oliu (38090) | more than 3 years ago | (#32631692)

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 (2, Interesting)

aj50 (789101) | more than 3 years ago | (#32631702)

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:Practicality (4, Interesting)

zippthorne (748122) | more than 3 years ago | (#32632292)

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:Practicality (1, Informative)

Anonymous Coward | more than 3 years ago | (#32631706)

You've never worked for an American corporation, have you? Most of the time, they're nothing more than civil wars between different managers and executives.

Re:Practicality (1)

SomewhatRandom (1299167) | more than 3 years ago | (#32631708)

What's the matter? Chicken? Buck Buck Buckaw! Sounds like a smoke-screen post from a 2nd-string programmer. (j/k - couldn't resist)

Re:Practicality (0)

Anonymous Coward | more than 3 years ago | (#32631716)

Besides all that is the fact that you're probably going to have to hire them at contract rates, costing you much more money per programmer multiplied by however many programmers. Having a cutthroat attitude amongst each other in the cubicles is something I'd only deal with if you paid me a lot more money than usual anyway.
 
A slight tangent, but recently I took a challenging grad class where we had to work in teams, and even though the other two guys were obviously not as skilled at coding (it was an interdisciplinary computing class, for one) I found that for pushing things through as fast as we needed to go -- especially when I was worn the fuck out -- having the other guys around helped quite a bit. So whaddya know, pair-programming can sometimes be good. Still, almost no one is ever going to do it because managers think it'll cost more money. (With older, surlier coders it likely would always be a waste of money.)

Re:Practicality (3, Informative)

hoggoth (414195) | more than 3 years ago | (#32631738)

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

Re:Practicality (0)

Anonymous Coward | more than 3 years ago | (#32631828)

That's amusing, but not in agreement with actual job listings where I live (USA -- San Francisco and NYC).

Re:Maintainability (2, Interesting)

Anonymous Coward | more than 3 years ago | (#32631796)

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 (1)

kiddygrinder (605598) | more than 3 years ago | (#32631858)

you're assuming that most programmers are competent, assuming that 1 out of 3 programmers are total gits this method looks a lot better

Re:Practicality (2, Interesting)

Puff_Of_Hot_Air (995689) | more than 3 years ago | (#32631880)

If you read the article, you will see that the intent is to find a non dodgy programmer, not a bare nuckeled cage match, winner take all. The article even suggests not letting either side know that there is another side. RTFA; yeah yeah, I must be new hear.

Re:Practicality (2, Insightful)

Opportunist (166417) | more than 3 years ago | (#32631912)

I was about to write that. If I ever find out you pit me in such a situation, and provided I do want that job, I will cut any corner possible to hit that milestone first. Does it require performance? No? Then it won't be performant. Will mem leaks matter? No? Then it will leak. I will not take care that the code is actually good. I will take care that it does exactly what the milestone requires. Not more, not less. Even if I have to unravel it completely because the design itself is unfit to do anything but hitting that first milestone.

That's what you get once your programmers notice such a practice.

Re:Practicality (1)

mfnickster (182520) | more than 3 years ago | (#32632022)

I was about to write that. If I ever find out you pit me in such a situation, and provided I do want that job, I will cut any corner possible to hit that milestone first.

Aren't you assuming that the competition is for speed and not quality?

The article recommends continuing with the programmer "you like best," and if you're just going by who's faster, you're probably going to suffer for it.

Re:Practicality (1)

Opportunist (166417) | more than 3 years ago | (#32632202)

I'm assuming that the competition follows the old market rule: Who's cheapest? When you're paying people by the hour, it's the fastest guy.

And yes, that's all that counts anymore. Quality is a myth everyone would really love to have but essentially, what people care about is cost. It's a bit like everyone wanting love, but prefering money in the end.

Re:Practicality (1)

mfnickster (182520) | more than 3 years ago | (#32632352)

But if you cut corners, it will end up being more costly in the long run.

I'm sure the managers aren't thinking about that, though.

Wrong expectations (4, Funny)

Chemisor (97276) | more than 3 years ago | (#32631652)

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 (0, Redundant)

JamesP (688957) | more than 3 years ago | (#32631820)

Protip: hire the three developers from different countries

Re:Wrong expectations (1)

Opportunist (166417) | more than 3 years ago | (#32631926)

So you get a bad one, one whose comments you can't read and one who needs an interpreter to misinterpret what your specs demand?

Yes, I had to work with code from abroad ("I think I have to polish my code a bit" "No, I think your code is Polish enough..."). Why do you ask?

Re:Wrong expectations (3, Informative)

DoofusOfDeath (636671) | more than 3 years ago | (#32631932)

Good call. They should hire four programmers!

Re:Wrong expectations (3, Interesting)

Noughmad (1044096) | more than 3 years ago | (#32632208)

Good call. They should hire four programmers!

Why not up it to eleven?

Re:Wrong expectations (1)

DoofusOfDeath (636671) | more than 3 years ago | (#32632384)

Why not up it to eleven?

Because even the manager isn't allowed to see it when it has eleven.

Why is this surprising? (0)

Anonymous Coward | more than 3 years ago | (#32631654)

Unfortunately, with all the kiddies getting a trophy for just showing up, I see a lawsuit in the future of this approach, with cries of "It's not fair!" Thank you 1960's!

Open Problem Vs Restricted/Closed Problem (1)

eldavojohn (898314) | more than 3 years ago | (#32631674)

I think that there are two major groups of problems out there. Yes, some problems are in both categories and I'm sure there's problems in neither category but the majority of problems out there are either a restricted closed space or an open space. In the former, you have a problem with a facet that dictates there is a best way to do things. For example, say you are building a database meant to create millions of records daily with a demand for instant querying. You're not going to want three people to tackle that three different ways. There's just a more simpler way of analyzing existing products and comparing strategies like federated search versus directory storage. Or sharded versus RDB. Or a number of other things that can be planned out on paper ahead of time and should be.

In the open scenario -- like designing the UI or mashup of many different pre-existing services -- then I think the proposed idea is a great idea. Because a human interface is more open with many different variables that are related in some unknown way to each other. UI isn't the only place this is applicable but we have used this strategy to develop several UIs before milestone one and then all discuss, come to a collective agreement and kill two.

Re:Open Problem Vs Restricted/Closed Problem (0)

Anonymous Coward | more than 3 years ago | (#32631760)

The goal isn't to find the best solution but the best programmer, with the understanding that the other ones will not be hired beyond the first milestone. The idea is simple: All programmers claim to know all languages, environments, methodologies, etc. that they're vaguely familiar with. How do you find the ones who actually do know what they need to perform on your project? You give them a shot at working on the project. While they're there, you can also check their work ethic and other "soft" aspects for which there are no certificates. Think of it as an internship with regular pay.

Re:Open Problem Vs Restricted/Closed Problem (1)

flajann (658201) | more than 3 years ago | (#32631888)

Oh, you mean like hire them for a month for a probation period? Keep the one you like and let the other one go? Hmmmm.... interesting idea. Might work if done right.

Alas, silly labor laws in your state/country might get in the way of doing it that way -- unless, of course, they were hired freelance/contract first. Even still, I can't even dream of pretending how all the various labor laws in all the various countries/states/cities would affect that approach.

But I like it (this is Manager Me talking!)

US Fed. Govt. does that, too, ... (2, Insightful)

Cragen (697038) | more than 3 years ago | (#32631676)

And has been doing large contracts like that for quite some time. Military, especially. Then, again, the Fed. Govt. is moving away from hiring contractors and is looking to hire permanent employees these days.

Re:US Fed. Govt. does that, too, ... (1)

luis_a_espinal (1810296) | more than 3 years ago | (#32632328)

And has been doing large contracts like that for quite some time. Military, especially. Then, again, the Fed. Govt. is moving away from hiring contractors and is looking to hire permanent employees these days.

Yeah, but the Gov. usually consider competing contractors on large-scale systems (not individual programmers or individual programming efforts.) Contractors have to pitch (hopefully) sound and technically feasible proposes using specific systems (not software, systems) engineering processes. Prototypes might be involved but they are submitted by the contractors as the result of team efforts within each contracting agency.

The scope of competition between contractors vying for a gov. contract vs individual programmers competing for implementing a web site or a e-business idea is really different by several orders of magnitude. One entails systems engineering (usually mid-to-large scale integration of electrical, computer, software and many times mechanical engineering). The other one will most likely reduce itself to a simple hackery contest.

First will sadly win (3, Insightful)

notthepainter (759494) | more than 3 years ago | (#32631684)

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

Re:First will sadly win (1)

Aladrin (926209) | more than 3 years ago | (#32631714)

Unfortunately, I think you are right. Only if the second comes in very close on the heels of the first, and is obviously better, would it win. As I said in a post below, companies can't judge 'good' software without an excellent programmer on staff to do the judging, and even then it could get twisted by politics.

Interesting idea, but... (4, Insightful)

Anonymous Coward | more than 3 years ago | (#32631694)

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.

Re:Interesting idea, but... (1)

Aladrin (926209) | more than 3 years ago | (#32631704)

Not sure why this ended up anon. It's mine.

Re:Interesting idea, but... (0)

Anonymous Coward | more than 3 years ago | (#32631776)

I will have spent days, weeks or months working for a company that doesn't want me around any more.

As an independent contractor I always work like this. It's a non-issue.

You list a bunch of attributes the code ought to be judged on, but I think you are overestimating the vast majority of programmers. Simple questions like "does it crash?" and "does it do what it's supposed to?" will be enough to weed out the innumerable dumbasses who work in this "profession".

Re:Interesting idea, but... (1)

Puff_Of_Hot_Air (995689) | more than 3 years ago | (#32631836)

Well, the article is talking about outsourcing; outsourcing to one. The situation presented is the small business looking for a non-shonky programmer for hire. This is more difficult than it may first appear! The web world particulary it appears. Case study: My father in law required a website/CMS system for his business. He allready had a basic website, but he was looking for a substantial upgrade. He hired a guy. This guy strung him along for several months, promising this and that, everything was 90% complete. Eventually my father in law got fed up, and demanded he just hand over everything in the state it was in. My brother in law, who is a web developer took a look at it. It was a cobbled together mess from various code-project projects. Nothing worked, and there was nothing to salvage. $5000 down the tube. Avoiding this is what hiring multiple guys is about. Give them one small useful increment and find out if their crap. Sounds like sage advice to me.

Pitching two developers, teams or even companies (1)

Sla$hPot (1189603) | more than 3 years ago | (#32631720)

Pitching two developers, teams or even companies against each other maximizes your change of success.
That is:
1. As management, you dont have a clue about what you are doing in the first place (go happy lucky)
2. You dont mind spending the cost two times over
3. To stay in power, You have learned to divide an conquer

But your cost will double
Your employees will start fighting and sabotaging each other

But who gives a $#!7 as long as your happy :)

Good in theory (1)

schnablebg (678930) | more than 3 years ago | (#32631728)

In the vast majority of businesses, especially small ones, getting to market has a lot more value than building great tech. It doesn't matter how good the tech is as long as it meets the business requirements from a black-box prospective. You don't need three independent projects to do that. The resources are almost always going to better spent on sales and marketing.

Code Competition may not always work!!!! (5, Insightful)

flajann (658201) | more than 3 years ago | (#32631744)

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!!!! (1)

Nerdfest (867930) | more than 3 years ago | (#32631780)

I've found that competitive design pays off better than competitive development. It's easier to refactor code than it is the complete design of a piece of software, so it's more important top get it right the first time. For code just use paired programming or a decent code review process (or both).

Re:Code Competition may not always work!!!! (1)

flajann (658201) | more than 3 years ago | (#32631840)

I've found that competitive design pays off better than competitive development. It's easier to refactor code than it is the complete design of a piece of software, so it's more important top get it right the first time. For code just use paired programming or a decent code review process (or both).

Oh I despise the "paired programmers" approach! Well, unless the pair are reasonably matched in competence and ability, I see no good coming out of it. And since I've been writing code for the past 30 years and have gotten rather good at it, I can't even conceive of who would be a good "match" for me in that scenario. If anything, I would wind up *teaching* rather than *coding*, which is how it usually goes anyway.

Re:Code Competition may not always work!!!! (1)

Nerdfest (867930) | more than 3 years ago | (#32632238)

The teaching is part of the intent, but yes it works poorly if there's a huge disparity in skills.

Re:Code Competition may not always work!!!! (0)

Anonymous Coward | more than 3 years ago | (#32632490)

I've found that competitive design pays off better than competitive development. It's easier to refactor code than it is the complete design of a piece of software, so it's more important top get it right the first time. For code just use paired programming or a decent code review process (or both).

Oh I despise the "paired programmers" approach! Well, unless the pair are reasonably matched in competence and ability, I see no good coming out of it. And since I've been writing code for the past 30 years and have gotten rather good at it, I can't even conceive of who would be a good "match" for me in that scenario. If anything, I would wind up *teaching* rather than *coding*, which is how it usually goes anyway.

Oh right, there is no one on God's green earth that is intelligent and experienced enough to be your match.. please.

Be a little more conceited.

Re:Code Competition may not always work!!!! (1)

Sla$hPot (1189603) | more than 3 years ago | (#32631832)

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

True. So you have to be a good communicator besides being a good system developer.
Often you have be good at smooching a litle bit too :)
Unfortunately, in most cases, being good at your profession is usually not enough when you work with IT
Thats is why you have to walk sometimes even thoug it can be tough.
But you can plan for it and you can learn to become better at navigating through bad projects ( learning by doing :)

Re:Code Competition may not always work!!!! (1)

JamesP (688957) | more than 3 years ago | (#32631856)

This is an interesting problem, and more of a 'customer relations' problem

Non tech people (and even tech people) have a funny way to understand things. If it doesn't look like it's working (even if you're building the foundations, etc) then, for all purposes, it's not working!

And I'd say, never, NEVER put the button if the code to make it work is not there. If you put the button they'll say "ok, now you just have to make it work *wink*"

Re:Code Competition may not always work!!!! (0)

Anonymous Coward | more than 3 years ago | (#32631902)

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.

I am so sick of programming done this way. If I can't use you program, the infrastructure and middleware is of no value. I hope you simply walk from any project I might end up using

Re:Code Competition may not always work!!!! (0)

Anonymous Coward | more than 3 years ago | (#32632550)

I am so sick of programming done this way. If I can't use you program, the infrastructure and middleware is of no value.

You sent this message using HTTP/TCP/IP, which were all designed extensively long before they had any kind of user-friendly interface, and which were therefore flexible and capable enough to become integral infrastructure behind every user interface in the world. Ironically, the only things valueless about your post were the "thoughts" it contained.

Re:Code Competition may not always work!!!! (1)

Dumnezeu (1673634) | more than 3 years ago | (#32631906)

Maybe you should focus more on an outside-in architecture. You start with what the user wants and end doing what you need to achieve that. Otherwise, you might start with what you think the user wants and end up with an interface for controlling that, instead of an interface dedicated to the needs of the end-user. Having a well designed back-end is very important, but not as important as a well designed front-end, because the user will care that something isn't work properly, but he will care about it a lot less than he will care about the fact that the option isn't even there! You just teach the user that bugs will always be fixed and he'll be happy to know that the next iteration will include the option he wants. If he doesn't even see the option on the screen, he just can't imagine it and he will think that you don't care about his needs. Users need slick front-ends and they don't give a shit about OOP, layering and all the other "details" involved in the process of programming quality applications. Maybe the company which wanted to pay for that project knew this and they knew that there would be time and money to re-factor the back-end as soon as the users saw a shiny interface and started paying for what they got.

In other words: Computer programming is very difficult, but that (unfortunately) doesn't work as an excuse for not packaging your product properly. Packaging is the only indicator that the user has to judge if your product is well done or not, because regular people just don't give a shit about any kind of abstract notion such as "performance."

The only performance the user cares about is how much faster he will be able to do his work using your product.

Re:Code Competition may not always work!!!! (3, Insightful)

OneMadMuppet (1329291) | more than 3 years ago | (#32632006)

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!!!! (0)

Anonymous Coward | more than 3 years ago | (#32632068)

Don't forget you are programming for end users, the UI is one of he most important things in a software application.
Looks like a lot of "great" programmers forget this and and although their app gets the job done it's a nightmare on users (see Lotus Notes).

Re:Code Competition may not always work!!!! (1)

bzipitidoo (647217) | more than 3 years ago | (#32632136)

To use a car analogy, on your way to getting a car built, which would you rather have first? A bare frame with wheels, engine and transmission, or an empty shell with a pretty paint job? I prefer the engine first, but seems that puts me in the minority. I'm continually astonished by how much stock most people put in appearances.

At my last job, the boss was supposedly a bright guy, but he was the sort to nitpick about the appearance of a web page (margins are too small was one of his favorite complaints) while thinking nothing of all the work behind the scenes to generate the data that the web page was supposed to display. My duties were primarily system administration, and I was constantly being accused of doing nothing. He'd think the work behind the scenes was trivial, and should only take a few hours. The web developers would make mess after mess, doing things in such horribly inefficient ways that once again systems were brought to their knees, and I'd have to clean things up somehow. If I could, I'd be on top of the situation before the RAID array ran out of space, and be logged in and still able to issue commands before the CPU utilization shot so high that even sshd was being starved. When I wasn't putting out fires, I was doing all I could to head them off. To be fair, the web developers were under a lot of pressure to bang out more bells and whistles as quickly as possible, so it was no surprise they took shortcuts to meet those demands, and never mind how much more work that made for me.

Re:Code Competition may not always work!!!! (0)

Anonymous Coward | more than 3 years ago | (#32632350)

To use a car analogy, on your way to getting a car built, which would you rather have first? A bare frame with wheels, engine and transmission, or an empty shell with a pretty paint job? I prefer the engine first, but seems that puts me in the minority. I'm continually astonished by how much stock most people put in appearances.

Leave the bad analogies to badanalogyguy. Ignoring the UI is like ignoring where to put the dashboard, the steering wheel, the ignition, etc., designing the engine, then putting the ignition under the hood, the steering wheel in the back seat and the dash on the front right side door.

Re:Code Competition may not always work!!!! (1)

westlake (615356) | more than 3 years ago | (#32632274)

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

Of course it is. The UI is how users communicate with your program. It is core functionality to them.

You build a car for the driver, not the mechanic.

Re:Code Competition may not always work!!!! (1)

hibiki_r (649814) | more than 3 years ago | (#32632336)

In a more generic way: Application quality cannot be measured at the time of delivery. It's usually many months before on can really say how good a custom app really is. Sometimes what seems like the best infrastructure ends up being the worst, because it was a lot less flexible than no infrastructure at all, and the requirements gathering that the system was designed from was faulty. Other times, the big infrastructure cost is more than warranted.

Using the obligatory car analogy: The car that has the best test drive isn't necessarily the best car after you've put 100K miles on it.

Re:Code Competition may not always work!!!! (1)

roman_mir (125474) | more than 3 years ago | (#32632542)

So you were given explicit requirements, instructions on how to 'win' in this competition, but you decided to go against these requirements and concentrate on something that was not as important to the stake holders instead and now you are complaining that competitive programming does NOT work?

You are the proof that competitive programming DOES work, it's just you failed in that competition.

If someone isn't skilled enough to compare... (3, Insightful)

Anonymous Coward | more than 3 years ago | (#32631772)

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.

Isn't that part of LEAN? (1)

nicc777 (614519) | more than 3 years ago | (#32631774)

Just worked on a project using LEAN [poppendieck.com] . What we would do is let all developers deliver the same prototype. At the end we evaluate each one, pick the best and move on. In diverse projects, different developers will excel in different areas. This was one way we could quickly see who is strong in which areas making later task assignments easier - especially when you are done with prototyping and now need to add all the other functional requirements. This sounds very similar...

Re:Isn't that part of LEAN? (1)

luis_a_espinal (1810296) | more than 3 years ago | (#32632376)

Just worked on a project using LEAN [poppendieck.com] . What we would do is let all developers deliver the same prototype. At the end we evaluate each one, pick the best and move on. In diverse projects, different developers will excel in different areas. This was one way we could quickly see who is strong in which areas making later task assignments easier - especially when you are done with prototyping and now need to add all the other functional requirements. This sounds very similar...

No, it is not. Not by a long shot. You are missing the entire point and essence of that practice.

The author of that ill-advising article is suggesting small businesses to hire three independent programmers (none of them working in collaboration, but in competition, and thus, not necessarily acting with anyone else interest in mind), and somehow be technically capable of evaluating which is the best (and only one to pick up.)

Yeah right.

The lean approach you are suggesting entails pitting ideas and designs for later evaluation by a team of colleagues. Yes, one design gets picked up as the primary contender. But chances are that other ideas from the other designs will be picked up and integrated to the final design as well. If this integration of ideas does not take place, and the only thing being done is to take a winner to the exclusivity of the other designs (which is what will happen with what the blog author is suggesting), then you are doing something wrong. That's not engineering.

Re:Isn't that part of LEAN? (0)

Anonymous Coward | more than 3 years ago | (#32632386)

That's not even close to Lean. It's pure waste generation. If a consultant told you this, it's time to fire him.

Personal Experience (1)

fantod (211355) | more than 3 years ago | (#32631784)

Before they fired me, we would hire people for a week or 2 week contract. I think this is much easier for both sides to manage than a milestone. I agree with some of the comments above. Having only the first win selects for the wrong sorts of traits. If you did the least amount of tasks because you were helping the other programmers, or adding documentation to the wiki, or identified and fixed one of the many core design flaws in the code, I'd still hire you.

Sounds a lot like free market economics (0)

Anonymous Coward | more than 3 years ago | (#32631788)

And also like free market economics, it will never work in reality and will probably actually end up sending everyone's computer back to the 1970s

People who use Linux have their heads up their ass (0)

Anonymous Coward | more than 3 years ago | (#32631852)

Fucking dick smoking queers.

bullshit; the most experienced of them will win (1)

zugedneb (601299) | more than 3 years ago | (#32631864)

if there is not much research or serious architecting involved, but mostly design, than the most experienced will win...

if it is a difficult poblem, than there is no win in developers hiding information from eachother...

Sweat Shop? (4, Insightful)

drooling-dog (189103) | more than 3 years ago | (#32631868)

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 (3, Insightful)

gweihir (88907) | more than 3 years ago | (#32631872)

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.

What happns when one is fast other slower better c (1)

Joe The Dragon (967727) | more than 3 years ago | (#32631884)

What happns when one is fast with rushed / buggy code and the other one is slower with better code?

Does the PHB pick the fast guy over the guy how is slower but has better code?

Christ, what a moron (4, Insightful)

0xdeadbeef (28836) | more than 3 years ago | (#32631896)

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.

Re:Christ, what a moron (1)

luis_a_espinal (1810296) | more than 3 years ago | (#32632394)

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.

Yep, pretty much.

And then what? (1)

Azarael (896715) | more than 3 years ago | (#32631938)

And who is to decide which programmers work is better? Hey wait..

Next you'll have to have another competition between two managerial candidates to see who does a better job of judging the programmers' work.

Gimmickry is not going to solve the issues that we have in software development. You can probably only count on two hands the number of true 'one size fits all' solutions and this isn't one of them.

Bad example: The Soul of a New Machine (2, Informative)

walmass (67905) | more than 3 years ago | (#32631946)

The story in TSNM: one programmer was asked to build something quick and dirty in 6 weeks, the other one was asked to build something much more detailed. the quick and dirty version was used until the detailed version came out 5 months after the first one. There was friendly competition, but this does not match at all the "one will fail, one will be so-so and one will be great."

No (0)

Anonymous Coward | more than 3 years ago | (#32631994)

No. Now get back to work.

False assumption (1)

slasho81 (455509) | more than 3 years ago | (#32631998)

This method of selection is based entirely on the false assumption that competition brings out the best of people.

Depends on the knowledge of the hirer (0)

Anonymous Coward | more than 3 years ago | (#32632024)

If one of the hired development teams hacks an app together in short time doing strictly what is required by milestone one, it can still be of poor quality because it can lack a grand design which can haunt the dev-team for the rest of all the milestones, in terms of scalability, documentation, neatness etc.
In short, milestone 1 in a fixed time setting, is a bad indicator of good code.
However if the hirer can look through these hacked up apps, He could make a better educated guess, but we all know the 'boss' never knows something about those "damned computers" and he loves shiny short reports and a working program developed by yesterday.

If you need experts in gaming the system-- (1)

dpbsmith (263124) | more than 3 years ago | (#32632086)

--then a task which rewards those who game the system is certainly a sound approach. :) ---Irony, note smiley.

Seriously, what message does this sort of thing send you employees.

1) We are willing to have people work on things that will never get used.

2) We like to fire people, two out of three in this case.

3) We do not trust any of you.

4) We enjoy imposing pressure that is not intrinsic within the task itself.

5) We do not trust our ability to recognize good programmers. Something to keep in mind at review time.

6) We judge by "results," meaning we do not judge the fundamental underpinnings of those results.

No (0)

Anonymous Coward | more than 3 years ago | (#32632144)

A "competition" like that tells the prospect far more about the hirer than vice versa. It tells the prospect to run.

A competition only tells you who has the most superficial knowledge. Because of the time limitation inherent in the competiton, you never learn who has the most forward potential.

Also, what does the loser tell in interviews for his next job? "Well, I worked there for six weeks, but the other guy got to stay on survivor island and I didn't." In other words, both sides invested 6 weeks of inculturation and learning about a program knowing that fifty percent of that investment would be wasted. Sounds like they're both idiots to me.

If you're so incompetent at picking talent that a "Survivor Island" process will waste less effort than traditional hiring with probation, you're to incompetent to be involved in the hiring process, and have so little respect for your direct reports that only someone with no self-esteem will work for you.
 

two examples: winning and losing (1)

John_Sauter (595980) | more than 3 years ago | (#32632154)

I have been involved in this sort of competition twice. In one case my group won the competition, in the other we lost.

In the first case our group was developing the software for the DN60-series of communication processors for the DECSYSTEM-10. Another group was developing equivalent software for the DECsystem-20. I whispered in the ear of the product manager, telling him that if the other group failed to deliver, we could port our product to the DECsystem-20 in three weeks. As it turned out, the other product was not satisfactory, so he told us to do the port, and we completed it on time. (Of course, we had started preliminary work on the port weeks earlier, but that work would have been wasted if we had not gotten the go-ahead.)

The second time this happened to me was on the software for the PrintSystem40, a large-scale printer built out of a high-speed copier, similar to a fully-expanded HP LaserJet 9000. Our group was in competition with another group for the on-board software and the print spooler. The other group's software was chosen, I think because our on-board software required a floppy disk drive for error logging and theirs didn't. We offered to send them our spooler, but I don't recall if they used it.

What about the employer's investment? (1)

Walter White (1573805) | more than 3 years ago | (#32632228)

Projects I've worked on include specifying requirements as a first step. That usually involves a huge investment on the part of the employer. They're going to have to spend even more time bringing three developers along. By the time the system is fully specified, it is likely that the weakest developer will have benefited greatly from the work of the strongest developer. That is likely to provide an overall improvement in the spec, but it won't make the decision making process any easier. At worst, the employer may get tired of answering similar questions and the last developer will suffer as a result.

Of course if there is a fully defined spec to work with, then the designer or programmer can start w/out a lot of employer involvement. I've never actually worked on a project like that but I suppose they do exist.

Define "best" (1)

mwvdlee (775178) | more than 3 years ago | (#32632244)

How will the company know which of the three programmers was actually best? Will they just look at how many features they managed to stuff in, no matter how badly hacked it is. I hope not.

No, they should also hire a code reviewer. Better still, they should hire three code reviewers in case the other two aren't any good at their job.
But how do you know which one is actually any good.

Better hire a code reviewer reviewer as well. Or three.

Sounds like this wasn't such a good idea in the first place ey? Guess whichever manager thought of this wasn't so smart. The company should have just hired three managers and let the board of directors decide how well he's doing.

Better make that three boards of directors and have three sets of stockholders decide which board is least incompetent.

And on and on until you come to the inverse of "atomic"; a point where it is no longer physically possible to have three separate larger units.

Re:Define "best" (1)

Murdoch5 (1563847) | more than 3 years ago | (#32632372)

How will the company know which of the three programmers was actually best?

Run there program under hard performance and stability checks. The one to pass all of or most of the test wins. What you should look for in the first code milestone is the ability that the code is clean, well put together and can be moved around for portability.

Better Development Through Competition?? (0)

Anonymous Coward | more than 3 years ago | (#32632312)

Holy Crapolie...

Welcome to 1900

BNR experience (1)

PsiCTO (442262) | more than 3 years ago | (#32632408)

Back when, Bell-Northern Research used to launch 2 or 3 parallel dev teams on a project and select the best result. Obviously they had cash to do that, but the key is that they let the teams run to the end. Each team got to complete a whole project and there were no winners or losers, at least as far as your career went in the company. At least that was the idea.

When budgets were tightened, they went back to a more traditional approach. I wonder if anyone did a study on those days... Might make a good thesis.

Anyone from those days care to comment?

...you'll pay more for worse programmers. (1, Insightful)

Anonymous Coward | more than 3 years ago | (#32632426)

See, there's real demand in the market for great programmers -- it's people that are not that good that are a dime a dozen.

So the natural result of making programmers artificially compete for a job is... either:

1. pay more to entice great talent who could get a job without the stupid competition elsewhere, or
2. resign yourself to seeing such talent disregard your offer and directly go elsewhere.

In the end, you'd end up paying more and getting less.

Competition is great when you have to talk (1)

istartedi (132515) | more than 3 years ago | (#32632472)

Competition is great when you don't have to talk to your competitors. When you chose a vendor or a product, competition rules.

If the "competitors" have to sit down and have lunch every day it's a different story.

I can see two possible things happening. If a particular team consistantly wins, this might initially seem like a good thing--you can just lay off and/or reassign the losers. Now, how good is that for morale? Even if the winners really are superior, will the knowledge that they are out the door if they lose a competition help them perform? Is that the kind of challenge that motivates people, or will they just decide to switch jobs to another company where this doesn't happen?

Are the best and the brightest really going to like this kind of environment?

Also, the "not the best" programmers might turn out to be more useful than you think. We may discover that having people who work at different levels of proficiency is actually valuable. Maybe those people are better able to explain the system to non-programmers. Maybe they are more patient explaining things. You might be taking the meat and potatoes off your plate with this strategy.

The other possible outcome is that people might collude to produce similar work. This kind of stuff happens at factory jobs all the time (don't work too fast, they'll speed up the line on us).

You know what you'll get? (1)

spiffmastercow (1001386) | more than 3 years ago | (#32632518)

There are 2 types of people who would accept this kind of condition: those who suck and those who are desperate. The desperate will leave as soon as their crises are over with, leaving only those who suck and can't find decent employment elsewhere.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>