Slashdot Mirror

← Back to Stories (view on slashdot.org)

Better Development Through Competition?

Posted by Soulskill on 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?"

23 of 251 comments (clear)

  1. Companies don't know by Herkum01 · · Score: 4, 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.

    1. Re:Companies don't know by khallow · · Score: 3, Insightful

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

      The fact is people make generalizations.

    2. Re:Companies don't know by tomhath · · Score: 2, 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 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.

  2. Practicality by Voulnet · · Score: 4, Insightful

    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.

    1. Re:Practicality by Opportunist · · Score: 2, 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 hitting that first milestone.

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

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
  3. US Fed. Govt. does that, too, ... by Cragen · · Score: 2, Insightful

    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.

  4. First will sadly win by notthepainter · · Score: 3, Insightful

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

  5. Interesting idea, but... by Anonymous Coward · · 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.

  6. Code Competition may not always work!!!! by flajann · · Score: 5, Insightful
    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.

    --
    Ruby Neural Evolution of Augmenting Topologies
    1. Re:Code Competition may not always work!!!! by OneMadMuppet · · Score: 3, Insightful

      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.

    2. Re:Code Competition may not always work!!!! by coryking · · 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!?

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

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

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

      You *should* do the GUI up front because the GUI dictates the design of the entire system. You don't have to make it hi-fidelity (i.e. functional)--you can get away with simple things like Paper Prototypes*. Let the design process be iterative and don't be afraid to throw bad ideas (literally). Paper is cheap, development time is not!

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

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

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

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

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

    3. Re:Code Competition may not always work!!!! by khaledh · · 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 developers who will maintain this code after you. I've had to deal with hundreds of thousands of lines of code with no documentation whatsoever, and it's not pretty.

      Finally, I want to mention that not giving the GUI enough attention from the beginning is not good also. I'm a believer that function and form are closely tied together. You can design the best infrastructure in the world, but slapping a GUI on top of it as an afterthought will result in crappy user experience. Also there are a lot of times where certain UI functions, although may seem trivial, actually translates to significant backend design changes. As you mentioned, the GUI is what the user interacts with, and to them it's actually the GUI that represents the application, so it *is* what the application is about to them.

    4. Re:Code Competition may not always work!!!! by coryking · · Score: 3, Insightful

      You need to develop the low-level stuff first, and do so well and solidly.

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

  7. If someone isn't skilled enough to compare... by Anonymous Coward · · 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.

  8. Sweat Shop? by drooling-dog · · Score: 4, 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.

  9. Not at all by gweihir · · Score: 3, 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.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    1. Re:Not at all by thePig · · Score: 2, 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 representations of qualitative and quantitative information, creating good test cases, creating bug proof code etc.

      But, even if the effort is not visible to my boss straightaway, I dont have to care, since I am confident that my boss has confidence in me and that I am not going to be a fungible commodity to him.

      If, as per mentioned in the article, that sort of competition and lack of confidence in workers is rife in the company, I am not going to create always the best output - rather I will be going to produce the safest output - the one with the most visibility - never mind how it performs later, after I get the advantages out of it. This is going to cause negative effects in the company in the long term.

      I was in a big (1 lakh + employees) company earlier. There I was considered an easily replaceable resource - even though my performance was quite good, with this amount of people, they could always get a better person than me to replace me. Even though I did not know it at that time, my performance was then less than optimum - i.e. I was not trying to improve myself a great deal - due to lack of confidence and this was a negative cycle.

      After quite a few years with this company, I was burned out, and I left to start my own company. Then I was absorbed (along with my product) by another startup. In the last 2 years, I think I have learned as much as the 10 years before in the big company - and my quality of work has now improved a great deal - this especially being because in the startup - and my own company - I gained a lot of confidence that I am in it for a long time.

      Actually, the aspects of confidence is extremely visible in sports etc, wherein if the player knows he is in it for a long time, he tries to play his natural game - and he is not hamstrung by the fact that a risky move will not jeopardize his career.

      Why the management in most companies do not understand this - I have no idea.

      --
      rajmohan_h@yahoo.com
  10. Christ, what a moron by 0xdeadbeef · · Score: 4, 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.

    1. Re:Christ, what a moron by 0xdeadbeef · · Score: 2, 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 offended if those suggestions get rejected.

      A good programmer has the freedom to find clients or an employer at a competence level appropriate to his own.

      It is remarkable, though, that people will blindly trust a programmer to make decisions on the safe handling of billions of dollars worth of data, and yet second-guess everything that programmer does that they can actually see.

  11. ...you'll pay more for worse programmers. by Anonymous Coward · · Score: 1, Insightful

    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.

  12. Re:Metrics by Anonymous Coward · · Score: 1, Insightful

    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.

  13. Re:My first employment by GarryFre · · Score: 2, Insightful

    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

    --
    www.Migrainesoft.com - Computer giving you a headache? We can fix that!
  14. Re:My first employment by Anonymous Coward · · Score: 1, Insightful

    And to follow GarryFre's football analogy, pitting your recruits against each other is called tryouts or training camp. You do this to discover which prospect will fit in best with the rest of your existing team.