Forgot your password?
typodupeerror
Programming

Better Development Through Competition? 251

Posted by Soulskill
from the there-can-be-only-one dept.
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?"
This discussion has been archived. No new comments can be posted.

Better Development Through Competition?

Comments Filter:
  • by Z00L00K (682162) on Sunday June 20, 2010 @09:24AM (#32631604) Homepage

    My first employment was handled that way.

    • Re: (Score:2, Insightful)

      by GarryFre (886347)
      Can you imagine a football, baseball or soccer team going about it each man for himself? People wouldn't have anything to cheer and these sports would be forgotten words. But if you work as a team you get a LOT done, and there' still competition to prove yourself a valuable PART of the TEAM! Programming is a team sport. A good team can accomplish a lot. Think about it. PS, I loved the woodpecker thing!! :D
      • by Barrinmw (1791848)
        They have one spot open on their team. They give that spot to 3 separate people to duke it out to find who would be best on their team. You are mistaken if you think this small group is the team. The team is the company, this isn't even a squad on the team, they are like mercenaries working for tenure.
      • Re: (Score:3, Informative)

        by furball (2853)

        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.

  • by Herkum01 (592704) on Sunday June 20, 2010 @09:30AM (#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.

    • by khallow (566160) on Sunday June 20, 2010 @10:05AM (#32631794)

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

      The fact is people make generalizations.

    • Re: (Score:3, Insightful)

      by tomhath (637240)

      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)

        by hedwards (940851)
        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 f
      • 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.

      • by microbox (704317)
        Most places I've worked the managers were once doing the job they are now managing.

        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
    • by wonkavader (605434) on Sunday June 20, 2010 @10:36AM (#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: (Score:3, Interesting)

        by jc42 (318812)

        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

        • by ultranova (717540)

          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.

          Maybe they should have a degree in computer science, then? One would imagine that that would help them judge the potential of a system.

      • by VTI9600 (1143169)

        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

    • by deuterium (96874) on Sunday June 20, 2010 @12:38PM (#32632846)

      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.

    • by mcrbids (148650)

      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)

    by Voulnet (1630793) on Sunday June 20, 2010 @09:31AM (#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: (Score:3, Interesting)

      by h2oliu (38090)

      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.

      • by jc42 (318812)

        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)

      by aj50 (789101)

      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)

        by zippthorne (748122) on Sunday June 20, 2010 @11:18AM (#32632292) Journal

        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)

      by Anonymous Coward

      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.

    • 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: (Score:3, Interesting)

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

      by Opportunist (166417)

      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

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

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

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

            • "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

    • 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

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

  • by Chemisor (97276) on Sunday June 20, 2010 @09:34AM (#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.

  • 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
  • by Cragen (697038) on Sunday June 20, 2010 @09:37AM (#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.
    • Seeing how much the government wastes, i would not consider that a glowing endorsement. And hiring feds is significantly cheaper than hiring contractors. Pay them more and you might even get good ones.
  • by notthepainter (759494) <obliqueNO@SPAMalum.mit.edu> on Sunday June 20, 2010 @09:37AM (#32631684) Homepage
    Not best, but first will win. That's my guess based on how most industries work.
    • by Aladrin (926209)

      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.

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

  • by Anonymous Coward on Sunday June 20, 2010 @09:40AM (#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.

    • by Aladrin (926209)

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

    • 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% com
  • 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.
  • 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.

    • by Nerdfest (867930)
      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).
      • by flajann (658201)

        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.

    • by JamesP (688957)

      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)

      by OneMadMuppet (1329291)
      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
    • 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

    • by westlake (615356)

      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.

    • by hibiki_r (649814)

      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

    • by roman_mir (125474)

      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.

    • by coryking (104614) * on Sunday June 20, 2010 @12:03PM (#32632616) Homepage Journal

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

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

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

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

      You *should* do the GUI up front because the GUI dictates the design of the entire system. You don't have to make it hi-fidelity (i.e. functional)--you can get away with simple things like Paper Prototypes [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!

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

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

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

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

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

    • Better to wait until a later stage when everyone has had a chance to think about what they really want.

      If people doesn't now what they want of the software, how do you know you're building the right architecture for them?

    • 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)

      by khaledh (718303)

      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

    • 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

    • by startled (144833)

      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

  • by Anonymous Coward on Sunday June 20, 2010 @09:58AM (#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.

  • Sweat Shop? (Score:5, Insightful)

    by drooling-dog (189103) on Sunday June 20, 2010 @10:18AM (#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 (Score:4, Insightful)

    by gweihir (88907) on Sunday June 20, 2010 @10:19AM (#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.

    • Re: (Score:3, Insightful)

      by thePig (964303)

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

  • by 0xdeadbeef (28836) on Sunday June 20, 2010 @10:22AM (#32631896) Homepage Journal

    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.

    • by VTI9600 (1143169)

      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)

        by 0xdeadbeef (28836)

        > 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 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.
  • by walmass (67905) on Sunday June 20, 2010 @10:30AM (#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."
  • This method of selection is based entirely on the false assumption that competition brings out the best of people.
  • --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

  • 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

  • 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

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

  • 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

  • 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.
  • Except... not : http://www.youtube.com/watch?v=u6XAPnuFjJc [youtube.com]
    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.
  • I think I would rather get hit by a car and then build a "jump to conclusions" mat.

    ft

  • Maybe Not (Score:3, Informative)

    by Javagator (679604) on Sunday June 20, 2010 @01:56PM (#32633332)
    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

    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.

  • 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)

    by Kittenman (971447)
    Written quickly or bullet-proof? Easily maintainable? With accompanying documentation or free-standing? Open and extensible?
  • 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.

Prediction is very difficult, especially of the future. - Niels Bohr

Working...