Forgot your password?
typodupeerror
Programming Software IT Technology News

Dragon vs. Hydra - Competing Development Styles 90

Posted by Soulskill
from the head-to-heads dept.
peterofoz writes "You may recall that we discussed a company which was recruiting talent with a puzzle last December. This turned out to be n-Brain releasing a new product that allows multiple editors to modify the same code in real time to support the collaborative programming paradigm. Now they're back with another challenge: 'Are two heads really better than one? N-BRAIN, Inc. intends to definitively answer this question by sponsoring the Hydra Versus Dragon Coding Competition, a Reality TV-style battle between the world's finest software developers.' Mark June 23rd on your calendars." While n-Brain clearly intends this to promote their software, it will be interesting to see if the competition results support their theory of collaborative development.
This discussion has been archived. No new comments can be posted.

Dragon vs. Hydra - Competing Development Styles

Comments Filter:
  • by FurtiveGlancer (1274746) <AdHocTechGuy@ a o l . c om> on Sunday May 18, 2008 @09:20AM (#23452534) Journal
    Collaboration depends on the collaborators. Some people collaborate better than others. Yet some shouldn't share the room with other humans. The answer is, it depends.
    • by quarrel (194077) on Sunday May 18, 2008 @09:33AM (#23452592)
      I really agree. One of the first things to learn in becoming a good manager is that different people are, well, different.

      Forcing everyone in to the same paradigm is hard..

      --Q
      • by FurtiveGlancer (1274746) <AdHocTechGuy@ a o l . c om> on Sunday May 18, 2008 @09:55AM (#23452716) Journal

        Doesn't that negate your cool handle?

        Seriously, I follow the advice of one particular grey-beard from my past, "Software ain't hardware and programmers ain't people." Programmers tend to be different: from secretaries, from accountants and from each other. The hardest part of successful coding or successful support is integrating whom you have into the best structure (or lack thereof) that you can establish to get the work done. Done well, it's a joy to behold. Done poorly, it's the Army.

        • Re: (Score:3, Insightful)

          by murdocj (543661)

          "Software ain't hardware and programmers ain't people." Programmers tend to be different: from secretaries, from accountants and from each other.

          No, programmers ARE people. Programmers are different, just like secretaries are different. Managers need to recognize the differences, and programmers need to understand that they aren't some superior breed of human. They are people who do different work.

          • by dogdick (1290032)
            Unfortunately in many of the jobs Ive held, I really have to have the "ARE people" stressed, and Im glad someone else said this. I dont think a lot of companies, people, and management realize that their software development teams are people.

            Ive felt generally under-appreciated at most of my jobs and that my job was completely misunderstood by anyone that isn't technical
          • The point of the aphorism is to express that, in my experience, programmers tend to be intelligent, creative, less structured souls. They are not your average office worker and should not be managed in the same vein.

            Motivation, for example, may have to be different. I used models of a tractor and a Corvette. The tractor went each week to the desk of the person with the clumsiest|ugliest working code produced. The Corvette went to the coolest idea|algorithm of the week. Some times they ended up on the

            • Re: (Score:3, Insightful)

              Wow. Really. You publicly humiliate a person each week? What a management style! I think it's called being an asshole.
              • by mcmonkey (96054)

                You publicly humiliate a person each week? What a management style!

                From where in that little tale of tractors and corvettes did you get public humiliation?

                • Public from most work environments being open these days and from the implications of the comments on attendance the day they were handed out. Humiliation for having it publicly pointed out that you had the worst code in the group.

                  If someone isn't up to snuff then their manager should talk to them about it in private. Come on, ranking the (perceived) quality of employees work in a way that makes it known to the other employees is just bullying and shaming. If that's the best management technique someone

              • You're one of those kids that got a cookie even when you were a screaming heathen weren't you. Poor performance != Reward|Apathy
                • You're one of those kids that got a cookie even when you were a screaming heathen weren't you. Poor performance != Reward|Apathy

                  Was that supposed to be a question? The problem is how management could deal with below average performance other than public shaming. Demonstrating that the only alternative you can imagine is to actively reward below average performance... well that says a lot about you and none of it is really very flattering.

            • I think using a tractor and a corvette is a bit silly. They're nothing alike. Tractors are excellent for the jobs they're intended to perform, while the corvette would be utterly useless. Giving a programmer a tractor for their code is, at best, sending a mixed message.

              What I think would be better is if the cool coder got the corvette, and took a huge steaming dump on the desk of the bad coder. Now that's motivation, and it also makes it clear exactly what you think of their work.

              • What I think would be better is if the cool coder got the corvette, and took a huge steaming dump on the desk of the bad coder

                The OP didn't say the tractor went to the bad coder, not even that the tractor was awarded for bad code. The tractor went for ugly/clumsy code that worked. Which makes sense. Generally tractors are not pretty, but they have a job to do and do it well. In the form-follows-function school, the tractor may be pretty when you understand its purpose and appreciate the lack of bells

                • You make an excellent point: As for the corvette, it's not any more of a compliment than the tractor is an insult. Corvettes go fast and look pretty, but aren't good for much else. Not exactly what we generally look for in code. Cool code isn't necessarily good code, and clever code is generally worst of all.

                  But that's not how the GGP described their use of the corvette, which was:

                  The Corvette went to the coolest idea|algorithm of the week.

                  Now, they didn't go into enough detail about the culture for me to be certain, but this does give me the impression that p

    • SLASHDOT Announces that N-BRAIN, Inc. has BOUGHT some ADVERTISING space at Slashdot. TAKE NOTE!
    • Also they seem to be forcing *remote* collaboration through their own collaboration product called "UNA". If they want to make it a real contest, they should force a contest between multiple people collaborating in the same room with one of them sitting in front of the keyboard with Microsoft Notepad, versus the same number of people collaborating remotely through this thing called "UNA".

      "One Microsoft Notepad vs. Multiple Commercial Copies of UNA", that would be a cool contest to do, and I'm not a Micros

    • Agreed. Some people collaborate with each other, the rest of us just clobber each other.
  • SubEthaEdit (Score:4, Interesting)

    by Caste11an (898046) on Sunday May 18, 2008 @09:21AM (#23452538)
    I've used SubEthaEdit [codingmonkeys.de] for years for this purpose.
    • Re: (Score:2, Insightful)

      by otomo_1001 (22925)
      And looking at it pricewise, 29 Euros versus 300 USD per person, SubEthaEdit seems a better choice.

      Not only that but their screencaps are awful, sized too big, focus is following the mouse disallowing you to actually see what they are trying to present, too much going on at once in general. And the music reminds me of a techno rave, a bad one at that.
      • Re: (Score:3, Insightful)

        by Jesus_666 (702802)
        I think the "Unstoppable" music is even worse. An IDE is not an action movie and trying to pass it off as one is, well... lame.

        The company desperately tries to be cool, but like everyone who does that they fail. Horribly.
        • by nuzak (959558)
          I blame YouTube. Seems every other video posted has some lame metal or techno background. I actually saw a vacuum cleaner demo with a thumpin' house beat.

      • We have another solution at my office (where we do pair programming stuff). Two people... sit next to each other... at the same screen, with two mice / two keyboards. (yay USB!)

        And if you need to do it remotely, one uses a program called "screen".

        • We have another solution at my office (where we do pair programming stuff). Two people... sit next to each other... at the same screen, with two mice / two keyboards. (yay USB!)
          And what do you use for the two cursors in two different parts of the document?
           
          • by FooAtWFU (699187)
            Such matters are silly fripperies (and we don't need 'em :P)
          • I haven't RTFA or really know much about this, but I thought the point of pair programming was that one did the typing while the other was free to really think about the problem and their solution to it. If you're both editing different parts of the 'document' (which would in this case mean code, right?) then isn't this the same as just splitting it into two files and having two people editing two different, but related, files? What's the benefit, aside from not having to compartmentalize your code as much

  • ...that if they're spending the money to sponsor it, it's pretty likely that they'll get the result they want.

    Personally, I think taking turns at the keyboard works just fine - it means that one of you is always reviewing, instead of having to produce code.
    • by gbjbaanb (229885)
      Personally I think that taking turns at the keyboard is fine too - one of you is always slee^H^H^H reviewing, instead of having to think :)

      My opinion is to never have 2 people working on the same chunk of code. 2 people, work on their own areas and then swap over to test, review (and if you want to be really extreme, document) the other guys' code. That'd sort the men from the professionals.
    • Actually, I would go even farther and say that if you ever have a situation where two people need to be typing into the same section of code at the same time, something is wrong with your development process and you are going to be in trouble. I could see this being useful in letting one type at a time, and many watch, but having multiple people typing in the same spot is asking for a mess.

      All that said, I'm not sure why this is becoming such a big deal right now. People in my Iowa State software enginee

  • by Cyberax (705495) on Sunday May 18, 2008 @09:35AM (#23452608)
    That's good for RealityTV but in real world I wouldn't want to work on a software where I have to struggle with other people editing the same file code at the same time.

    In 99% of situations you should just modularize your code to minimize conflicts, not try to make them 'nicer'.
    • I agree. What exactly is going on here? Two guys are changing the same piece of source at the same time? Either it's a small piece of code in which case their changes are right next to each other - so having two people doing it seems really stupid, inefficient etc. etc. - or it's a large piece of code in which case it should have been broken up into smaller pieces in the first place. Check out your small module, edit it, check it back in. Multiple simultaneous editing just seems like the wrong solution to t
  • by antirelic (1030688) on Sunday May 18, 2008 @09:47AM (#23452660) Journal
    Even though Dragons and Hydra's have roughly the same hit dice, lets face it, Dragons have a much lower AC and can deal and take alot more damage. Plus the fact that they can fly...

    Wait... I'm gonna go read the summary quick...
    • What the hell are you talking about? A hydra can burrow and wait for a queen to broodling it. The dragoon doesn't stand a chance.
    • by turing_m (1030530)
      The one exception is where all hexes surrounding the hydra are filled with dragons.
    • I had the misfortune to be attacked by a hydra:
      100% hp
      Hydra strikes you with its head dealing massive damage!
      Hydra strikes you with its head dealing massive damage!
      Hydra strikes you with its head dealing massive damage!
      Hydra strikes you with its head dealing massive damage!
      Hydra strikes you with its head dealing massive damage!
      Hydra strikes you with its head dealing massive damage!
      Hydra strikes you with its head dealing massive damage!
      Hydra strikes you with its head dealing massive damage!
      2% hp

      Lucky it didn
  • by FurtiveGlancer (1274746) <AdHocTechGuy@ a o l . c om> on Sunday May 18, 2008 @09:47AM (#23452664) Journal
    I wonder if there will be a quality review of the code and comments before they declare a winner?
  • by consonant (896763) <shrikant.nNO@SPAMgmail.com> on Sunday May 18, 2008 @09:51AM (#23452692) Homepage
    A coding reality show on TV! Watch the dragon takeon the hydra! Damn, that would make some compelling television. I'd even accept it on pay-per-view!

    "Watch seasoned developers and greenhorn programming prodigies square off their skills against each other! The algorithms will clash and the development environments will see sparks fly!"

    I'd say the second episode of this series would be a vi vs emacs thing..

    p.s: and vi would win ;)
    • by dodobh (65811)
      The first would be C++ vs Java, with the challenge involving fork and dropping privileges multiple times.
    • by SoulRider (148285)
      vi vs emacs thing

      That would be cool because no matter who they picked we would get to see some "Full Contact Coding". Come on "ARE YOU READY TO RECURSE".
  • by Anonymous Coward on Sunday May 18, 2008 @10:23AM (#23452890)
    Developers are most productive when they are in the groove. Distractions kill productivity. Collaboration causes distractions, ergo collaboration decreases productivity. http://www.byte-vision.com/ProductivityArticle.aspx [byte-vision.com]

    "The Mythical Man Month" points out that adding people to a project often/usually slows it down. http://en.wikipedia.org/wiki/The_Mythical_Man-Month [wikipedia.org]

    The best development model I can think of is Linux. Everyone works on their own thing and submits it when it is ready.
    • Re: (Score:3, Insightful)

      by nuzak (959558)
      "The Mythical Man Month" points out that adding people to a project often/usually slows it down.

      Ergo, the fastest projects have nobody working on them.

      I think Brooks might have been aiming at something more nuanced.

      • by mcvos (645701)

        "The Mythical Man Month" points out that adding people to a project often/usually slows it down.

        Ergo, the fastest projects have nobody working on them.
        It's true! In fact, it reminds me of another quote: Every program can be reduced by at least one statement, and contains at least one bug.

        Ergo, every program can be reduced to one statement that doesn't work.
    • by turbidostato (878842) on Sunday May 18, 2008 @12:04PM (#23453582)
      ""The Mythical Man Month" points out that adding people to a project often/usually slows it down."

      Does "stupidly stupid" exists? I'd say that's what you earned with such a claim.

      As a previous answer to you post already stated, that would mean that the fastest project would be that with *no* resources at all asigned.

      What the Mythical Man Month points out is that adding people to *an already delayed project* will usually delay it even more (due to the need to bring to speed the new resource). Quite a different thing.
      • by arevos (659374)

        What the Mythical Man Month points out is that adding people to *an already delayed project* will usually delay it even more (due to the need to bring to speed the new resource). Quite a different thing.

        From what I recall it was more general than that. The MMM points out that it's hard to scale teams that have heavy intercommunication. Assembly lines can be scaled well, because each worker doesn't really need to talk to the next. Software projects require a great deal of intercommunication, so scaling them is hard.

        The MMM further postulates that there is a point at which the disadvantages of communicating with a large team outweighs the advantages of having more people. So a team of 20 might be able to ou

        • "From what I recall it was more general than that."

          Yes, of course. But we were talking about chapter 2 (which is the one called "the mythical man month" itself, by the way).

          "Software projects require a great deal of intercommunication, so scaling them is hard."

          While this is the "first read" from MMM, there's a slight point to be noted. It is not software projects that require a great deal of intercommunication, but that *when* a great deal of intercommunication is needed, there's a curve with a point beyo
    • Developers are most productive when they are in the groove. Distractions kill productivity.
      I would argue that's true to a point. Once you've exceeded a couple of hours, then it's useful to have a distraction. Otherwise, you end up with poorly designed, monolithic chunks of code. If you fully designed beforehand, then it would be less of a problem...but that's just crazy talk.
  • by njcoder (657816) on Sunday May 18, 2008 @10:37AM (#23452992)
    Collaborative programming has been around for a while. It's just now that components are being developed, computers can handle it and the networking bandwidth is accessible, so that users can do it remotely.

    You used to take a chair, plop it next to one guys computer and swap the keyboard back and force when someone got stuck, tired, bored or needed to piss out the 10 liters of jolt he just chugged. It's called pair programming. I guess people never envisioned that you could get more than 2 people looking at a 14" crt in a reasonable way.

    Times have changed but the principles are basically the same. Multiple people looking at the code as it's being written helps in a lot of situations. Senior developer working with junior developer to help asses his abilities and to familiarize him with the specific api's, coding styles, etc.

    My best experience was working with another developer in a marathon coding session. We were both working with something very new to us. We had two computers side by side and if either one of us had an issue we would focus on that one pc. Even though we were working on different parts we were both knowledgeable enough about what the other was doing so that if one of us passed out for a couple of hours the other could take over if necessary, or just swap if we got bored.

    When I was managing a group of developers I tried to sit down with individual developers and go over code together when there was a problem. What I found is that I may not always have had the answer but by working together the answer was easier to find. Someone could say something that triggers something in the other person. Plus sitting there and showing how I went through to find the relevant API docs and doing google searches, even when I knew the answer, shows them how to do it themselves later. This was back when google, im, etc were all new.

    Now, with more collaborative tools people can do the same thing remotely. And it can be a help or a hindrance depending on the people involved. IM is good for sending code fragments, phone or skype is good for communication, but it's better to be there in person. A lot of complicated problems don't get solved at the keyboard. They get solved through weird hand motions, scribbles on a notepad or whiteboard.
  • A quick browse through TFA completely fails to inform me what the "Dragon" and "Hydra" in question actually are, other than that "Dragon" is something or other traditional and "Hydra" is some kind of ZOMG amazing new silver bullet.

    Anyone who understands the buzzwords care to cut the crap and explain what this is actually all about?
    • by pohl (872)
      A dragon is a mythical serpent. It has one head. A hydra is another mythical serpent. It has many. Heads contain brains. Brains are important to programming. The rest is left as an exercise to the reader.
    • Re: (Score:3, Funny)

      > A quick browse through TFA completely fails to inform me what the "Dragon" and "Hydra"
      > in question actually are, other than that "Dragon" is something or other traditional
      > and "Hydra" is some kind of ZOMG amazing new silver bullet.
      >
      > Anyone who understands the buzzwords care to cut the crap and explain what this is actually all about?

      All I know is that if someone doesn't travel to someone else's dojo and humiliate him in front of his master, I'm going to be sorely disappointed.
  • Coding together realtime in the same environment will not solve anything.
    • Errors introduced by bad programmers are more easily solved by replacing them than by working together with them realtime
    • If you do not have the time to do peer reviews of fellow co-workers code non-realtime, what makes you think you have the time when you are programming?
    • Having more than one person "working" (only one can work, otherwise it end up being a mess of different oppinions on how to write the particular piece of code) on the
    • That's one approach. Another approach is when the other person is within reach and can answer questions or you can each delegate small chunks in real-time, as occurs in many physical tasks with experienced partners. Experience with a coding partner is invaluable this way, and won't be solved by an editor. But the editor can cooperate by easing whitespace discrepancies, encouraging consistent formatting for legibility and easy comparison, using sane 'commit' and 'save' policies, etc.
  • by Antique Geekmeister (740220) on Sunday May 18, 2008 @11:15AM (#23453276)
    Theo de Raadt.
  • dragoon > hydra
    • depends on the range upgrades!
    • dragoon > hydra

      Anyone who leaves a single hydra by itself deserves to lose it! Are you sure you're accounting for the nearby pair of burrowed zerglings (a.k.a "developer interns", to stay on topic)?

  • by Ilan Volow (539597) on Sunday May 18, 2008 @12:31PM (#23453776) Homepage
    Simply for the hot groupies who will obviously throw their bodies at me when I win.
  • by crunchy_one (1047426) on Sunday May 18, 2008 @12:45PM (#23453880)

    Since the competition is designed by, sponsored by, and conducted by folks with a point to prove, the outcome is not in doubt. The hydra is gonna kick the dragon's ass.

    I've been writing code professionally since 1976, and have had to endure more than my share of management-instigated nonsense, including various stabs at a "collaborative development" work environment as an attempt to end-run "Mythical Man Month." It's like trying to build a perpetual motion machine while making all of your employees suffer.

  • What a mess. There can be times when two heads are better than one, but other times not so. Who decides this? Silly contests? It usually is when one guy knows a little more than the other and can help improve the skills of the slightly lesser coder to continue on his own (this could work both ways). I know I code better when I am around great coders. But, so much for the actual code. I can't help but feel that much of this is more of a management brain fart where they think two guys can get something done t
  • Invalid competition (Score:3, Informative)

    by PipingSnail (1112161) on Sunday May 18, 2008 @03:50PM (#23455240)

    For the competition to mean anything the Dragon and Hydra teams should be trying to solve the same problem. But they aren't. The rules explicitly state they are solving different problems. Talking about starting your test with a built in bias (which ever way that bias is).

    And thats not even counting the issues of talent of individual team members and if those particular participants are well suit to working well with each other (as opposed to working well with someone else or on their own).

    Stuff and nonesense. As others have noted, good design and modularity are good starting points. I've worked with some great people in my time and none of us would ever want someone else editing the same file at the same time as they were.

    I'm also not convinced that you will get the greatest talent entering this competition either. You may get lots of young, eager people, some of which may be talented, but anyone old enough to have been around to know what works for them and for their colleagues, I doubt very much they'd be interested. Fame, get on a TV show? No thanks, way too shallow and vacuous. Neither of which are attributes I've found in people I regard as talented.

  • Will be a Russian mythical creature, that is a cross between a hydra and a dragon!
  • I've seen a lot of benefit in developers bringing in a projector and working together on design/code with a wall-sized screen that they can both look at. Only one person might be manning the keyboard and mouse, but it's so much more conducive to longterm discussion than when multiple people crane over a shared monitor, even a nice widescreen. An afternoon of great collaboration can happen that way . . .
  • I'd say that the fact that the Qualifying Requirements include:

    1. You know the Java 5 programming language.
    pretty much guarantees that none of "the world's finest software developers" will be involved in this competition. I feel dirty just reading about it.
    • by mcvos (645701)

      I'd say that the fact that the Qualifying Requirements include:

      1. You know the Java 5 programming language.

      pretty much guarantees that none of "the world's finest software developers" will be involved in this competition.
      Not at all. Many of the world's finest software developers do know Java 5, and recognised it as a sign to move on to things like Ruby and Python.
    • by SoulRider (148285)
      See this is why there could never truely be a "worlds finest software developer", because all software developers think they are "the worlds finest software developer". N-BRAIN is going to have to invite all software developers to participate, they would need a venue the size of Texas to sponser that. What I would like to see is a "Survivor" type of show, where a bunch of "joe average" coders have to code their way out of a situation or die. Hmm, that just might actually make it on TV, I know at least a do
  • All this experiment will show us if technology is at a level to....

    rid us of the problems with resolving, merging, and hopefully an ease to file versioning.

In a consumer society there are inevitably two kinds of slaves: the prisoners of addiction and the prisoners of envy.

Working...