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?"
My first employment (Score:3, Funny)
My first employment was handled that way.
Re: (Score:2, Insightful)
Re: (Score:2)
Re: (Score:3, Informative)
This is how America's Special Forces work. The team gets a mission. Everyone comes up with a plan. The team goes over the plan. The good one emerges. The ones not as good fade out. Everyone pokes and prods the good plans until they figure out which one is going to bring about the mission results.
That is the plan the team executes. But at the beginning, everyone on the team has a plan.
Companies don't know (Score:5, Insightful)
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 (Score:4, Insightful)
The fact is companies like to treat most jobs, excluding management positions, as unskilled labor.
The fact is people make generalizations.
Re: (Score:2)
Of course they do, that's what separates them from apes. It's been a pretty succesfull strategy this far.
I HATE people who generalise ... (Score:2, Funny)
Re: (Score:2)
fat bald middle-class suburban under-achieving married white people
"How did he know? ... How did he know?"
Re: (Score:3, Insightful)
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 m
Re: (Score:2, Redundant)
Sucks, but that's what you get f
Re:Spring (Score:2)
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: (Score:2)
This is true, but people aren't promoted because they know how to program. Last IT shop I worked at, the most skilled manager didn't understand that DLLs were loaded with the program. The previous guy couldn't grok what encoding was all about, and used & through trial and error.
A famous book from the 80s, "Peoplesoft" talks about some of the insane chronic disconnects between management and developers, and these sam
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: (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 t
Re: (Score:2)
Maybe they should have a degree in computer science, then? One would imagine that that would help them judge the potential of a system.
Re: (Score:2)
You can swap 'em around and get the same result.
This is certainly a typical programmer's perspective on management's attitude. But, what you don't often see represented on /. is the reality that many programmers are prima donnas who vastly overestimate their own genius to the detriment of the projects they work on.
These sorts of programmers refuse to write comments (let alone end-user docs) because they say, "my code is self-documenting", while you're looking right at it and can see nothing but spaghetti. They come up with bizarre database schemas and
Re:Companies don't know (Score:5, Informative)
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.
Re: (Score:2)
As an employer, I can say with confidence that I'm NOT looking to commoditize my programming team. I WANT developers to be valuable, because when they are valuable, I can charge more for their work. I'm more than happy to pay my developers more, but the difference in value makes it more profitable for me as well.
In my opinion, managers who try to make their programming team lack value are doing the same for their company. And why would you want to work to ensure that your company offers no value?
Better prog
Practicality (Score:5, Insightful)
Re: (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: (Score:2)
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.
Hey, where do live, that has such a problem? Where I live (the Boston area), most of the software people I know are only semi-employed or unemployed. Around here, it'd be pretty easy to get together a good-size team, and put them to work coming up with multiple solutions to software problems, then testing them to learn which ones are good for what part
Re: (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: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: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: (Score:2)
Re: (Score:3, Interesting)
Re: (Score:3, Insightful)
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
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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.
Re: (Score:2)
"But if you cut corners, it will end up being more costly in the long run."
That's only if there's a "long run" *and* the one paying in such a long run will be you. If there's no "long run", then your "quality" is plain old "overburden"; if there's to be "long run" but the ones paying for it are "others" (for a varying definition of "others") then it's "externalities".
"I'm sure the managers aren't thinking about that, though."
Mostly they do. And don't give a damn because that's not what they are being paye
Re: (Score:2)
As a developer I agree with you, but I'll also play devil's advocate here for a second.
I'm the most cooperative person. Always helping people. Sharing ideas... Yet, after years of interviewing people for positions, I sometime question if my cooperative nature is actually a problem.
They all come in with great resumes, but really don't know much.
Does it actually prop up bad people? Management only cares about results, as they should... and if I'm propping up someone, it shields them from failure and thus
Work together (Score:2)
If you have to uncooperative programmers that can't work in a team, then this programming competition could work, but be ready for increased chance of burn out. In general though getting these two programmers working together is probably the best of action. There is a lot to be said for bouncing ideas off each other and motivating each other.
Re:Practicality (Score:4, Informative)
Contract rates? Where have you been the last 10 years. Contract rates start at 10 rupees.
Wrong expectations (Score:5, Funny)
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 (Score:4, Informative)
Good call. They should hire four programmers!
Re: (Score:3, Interesting)
Good call. They should hire four programmers!
Why not up it to eleven?
Re: (Score:2)
Because even the manager isn't allowed to see it when it has eleven.
Re: (Score:2)
http://www.youtube.com/watch?v=V7__SWWSaGM [youtube.com]
Re: (Score:2)
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: (Score:2)
Open Problem Vs Restricted/Closed Problem (Score:2)
Re: (Score:2)
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, ... (Score:3, Insightful)
Re: (Score:2)
First will sadly win (Score:4, Insightful)
Re: (Score:2)
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.
Re: (Score:2)
TFS mentions "The Soul of a New Machine". The reason Data General ran a parallel effort was that they needed a product "yesterday" (to compete with VAX). They went to market with the first completed project and did well with it. If they had waited for the other team to cross the finish line the race might already have been lost. Sometimes time is of the essence.
That book was a great read.
Interesting idea, but... (Score:4, Insightful)
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: (Score:2)
Not sure why this ended up anon. It's mine.
Re: (Score:2)
Good in theory (Score:2)
Code Competition may not always work!!!! (Score:5, Insightful)
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: (Score:2)
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
Re: (Score:2)
I can't even conceive of who would be a good "match" for me in that scenario.
Linus?
Re: (Score:2)
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: (Score:3, Insightful)
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
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
Re: (Score:2)
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.
Re:Code Competition may not always work!!!! (Score:5, Insightful)
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!?
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.
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 [alistapart.com]*. Let the design process be iterative and don't be afraid to throw bad ideas (literally). Paper is cheap, development time is not!
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!!!! (Score:4, Insightful)
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!?
Re: (Score:2, Redundant)
The front-end is the whole point of the program. If it isn't driving the backend development, you are doin' it wrong. Companies who let the backend drive development get blown away whenever something new comes along.
Re: (Score:2)
If people doesn't now what they want of the software, how do you know you're building the right architecture for them?
Re: (Score:2)
Right,
this is the trade-off,
the flip point is that the software that looks prettiest - will often be perceived to work best by the end customer as well. Software programming is part math, and part theater.
Perhaps scalability can wait longer than the PowerPoint OS version?
Re: (Score:2, Insightful)
It's precisely because infrastructure code is not visible to the end user that you have to sell that (supposedly elegant) infrastructure some other way. You need to explain what's going on behind the scenes and why it is important on the long term. Upper management will appreciate simple block diagrams explaining that this kind of infrastructure will give them a lot of flexibility and maintainability down the road, reducing the cost of change and bug fixes.
Documenting the backend is also important for other
GUI is more important but... (Score:2)
Others have noted that the GUI is actually the more important part. The underlying systems should be subservient to the needs of the GUI, to make what is required possible.
That said, maintenance of something once built is usually pretty important too.. If I were running something like the competition you were imn, I'd actually evaluate who did the best GUI, and who built the best backend (based on code review and a description from each team on how the infrastructure was laid out). Then I'd have that ba
Re: (Score:2)
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'll settle for the one that HAS A GUI.
This guy's advice is good for his target services and audience. In particular: he's giving advice with no existing relationship with a programmer, who are going to jump feet-first into elance, guru, odesk, and vworker. These first-time users of the services will be lucky to see a project through to a remotely satisfactory conclusion if they only hire one programmer.
Having been in that position once, I can vouch for what he's saying: you'll be ignorant enough of the cri
If someone isn't skilled enough to compare... (Score:3, Insightful)
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? (Score:5, Insightful)
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 (Score:4, Insightful)
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.
Re: (Score:3, Insightful)
I agree with all your points. I would also like to add the effect of confidence.
For me, if I am confident that I am in it for the long term, my effort goes up quite a bit.
The effort is not fully visible to my boss all the time - since most of the effort goes in non-obvious, but nevertheless extremely important aspects of programming - thinking deeply about design and deciding the exact architecture which can handle most of the future enhancements, creating the best aspects for UI design and exact representa
What happns when one is fast other slower better c (Score:2)
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 (Score:5, Insightful)
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: (Score:2)
How is a programmer any more qualified to do UI design than a business person, who we can assume has at least some idea about how he wants people to use the software? Who's capital is being risked in this scenario (excluding of course lame offers of equity in exchange for labor)? The person taking the risk should have the final say on the design even if you don't agree with it. A good programmer would make suggestions for UI design, but not become offended if those suggestions get rejected.
Re: (Score:3, Insightful)
> How is a programmer any more qualified to do UI design than a business person
How is a business person more qualified to understand business than a programmer, who we can assume has at least some idea of the business domain he is modeling?
Sounds pretty stupid when you put it that way, doesn't it? So why do you assume that user interface design isn't part of the repertoire of any programmer who writes customer-facing applications?
> A good programmer would make suggestions for UI design, but not become
And then what? (Score:2)
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 (Score:3, Informative)
False assumption (Score:2)
If you need experts in gaming the system-- (Score:2)
--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 ti
two examples: winning and losing (Score:2)
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 p
Define "best" (Score:2)
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 wh
A million monkeys... (Score:2)
Has the same problem; identifying the best is another problem, and even identifying metrics for determining the best is far from obvious. As fortune keeps reminding me: "Any sufficiently advanced technology is indistinguishable from a rigged demo".
Re: (Score:2)
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.
...none of which you can test by...
Run there program under hard performance and stability checks. The one to pass all of or most of the test wins.
Competition is great when you have to talk (Score:2)
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
You know what you'll get? (Score:2)
You need incentive to do a good work (Score:2)
The video is good but the tl;dr is : give monetary incentive for an intellectual work, the more you pay people the LESS they work. That is the result of a few sociological studies. Give programmers a good enough pay so that he doesn't worry about money, give him autonomy and challenging objectives and you'll get better result than with a promise of a 20k$ bonus.
Jump to Conclusions (Score:2)
I think I would rather get hit by a car and then build a "jump to conclusions" mat.
ft
Maybe Not (Score:3, Informative)
The book mentioned in the summary is about a project at Data General. I think it is interesting that they aren't in business anymore.
At my company, every one knows who the best programmers are, even management. We don't need this kind of nonsense.
Heard of a similar experience (Score:2)
The development competition is nice when the project is very short, and no quality is needed, so most of the consultants projects are in this category.
However, it's the most terrible approach for long time projects.
One of my colleagues explained me that in his previous job, there were 2 software architects who competed this way when a new extension in their project was needed.
The winner was never chosen by the code quality, but by the first delivery, so I can only imagine how terrible is the code to maintai
Define "good" (Score:2, Informative)
The Fat Part of the Bell Curve (Score:2)
Given that, in the majority of cases, solution #1 will be no better than 10% better than solution #2, is paying 200% worth it? What guarantee do you have that the succeeding project (of a slightly differing nature) would be better executed by the team winning the first? Life is fraught with such complications, rendering generalizations of this sort moot.
Re: (Score:2)
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: (Score:2)
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.