Beta
×

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

Thank you!

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

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

Dragon vs. Hydra - Competing Development Styles

Soulskill posted more than 6 years ago | from the head-to-heads dept.

Programming 90

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.

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

Hydra by Two Noses? (3, Insightful)

FurtiveGlancer (1274746) | more than 6 years ago | (#23452534)

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.

Re:Hydra by Two Noses? (3, Insightful)

quarrel (194077) | more than 6 years ago | (#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

You Agree, Quarrel? (3, Funny)

FurtiveGlancer (1274746) | more than 6 years ago | (#23452716)

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:You Agree, Quarrel? (2, Insightful)

murdocj (543661) | more than 6 years ago | (#23453706)

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

Re:You Agree, Quarrel? (1)

dogdick (1290032) | more than 6 years ago | (#23454656)

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

I Agree and Don't Want to Quarrel! (1)

FurtiveGlancer (1274746) | more than 6 years ago | (#23454680)

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 same desk for the same project. Monday morning was when the models moved. We had no attendance problems on Mondays.

Re:I Agree and Don't Want to Quarrel! (2, Insightful)

Have Brain Will Rent (1031664) | more than 6 years ago | (#23455118)

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

Re:I Agree and Don't Want to Quarrel! (1)

mcmonkey (96054) | more than 6 years ago | (#23464072)

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?

Re:I Agree and Don't Want to Quarrel! (1)

Have Brain Will Rent (1031664) | more than 6 years ago | (#23472834)

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 can come up with then they shouldn't be a manager.

Re:I Agree and Don't Want to Quarrel! (1)

BlargIAmDead (1100545) | more than 6 years ago | (#23465616)

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

Re:I Agree and Don't Want to Quarrel! (1)

Have Brain Will Rent (1031664) | more than 6 years ago | (#23472872)

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.

Re:I Agree and Don't Want to Quarrel! (1)

totally bogus dude (1040246) | more than 6 years ago | (#23458454)

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.

Tractor and Corvette (1)

mcmonkey (96054) | more than 6 years ago | (#23463968)

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 and whistles. Likewise, the ugly code needed to solve an ugly problem can be pretty.

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.

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.

Obviously the entire exercise is silly. Obviously a tractor is not like a corvette. Tractors are excellent for the jobs they're intended for, just like ugly working code. Corvettes are flashy and useless, just like most attempts by programmers to be clever.

So what's the problem? Are you just troubled that somewhere there's a workplace with a little silliness?

Re:Tractor and Corvette (1)

totally bogus dude (1040246) | more than 6 years ago | (#23469016)

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 people would want to be awarded the corvette. If this is the case, then you have people competing to try to be clever and come up with "cool" ideas/algorithms, which as you say isn't necessarily what you want out of your programmers.

As for the tractor, ugly code isn't pretty. Ugly code is going to be a burden to the project, because if it "works" it still needs to be maintainable. Ugly problems can be solved with pretty code, but ugly code doesn't become pretty just because the problem it's trying to solve is even uglier. I got the impression that the tractor was something the coders wanted to avoid receiving. If it's not, then it's even more problematic because the last thing you want is your developers trying to compete with each other to write the ugliest, but working, code.

Also note that they said both toys often ended up on the same desk for the same project: this suggests the corvette isn't used to reward good code, merely good ideas, and it's no surprise that people trying to come up with cool ideas and algorithms wind up writing ugly code.

So what's the problem?

The problem was I was trying to make a joke, which obviously didn't work. This is what troubles me. I don't particularly care about and didn't give much thought to the practice itself, but now that I have it does seem like a silly idea with questionable benefits.

Re:Hydra by Two Noses? (1)

Frosty Piss (770223) | more than 6 years ago | (#23454206)

SLASHDOT Announces that N-BRAIN, Inc. has BOUGHT some ADVERTISING space at Slashdot. TAKE NOTE!

Re:Hydra by Two Noses? (1)

stephanruby (542433) | more than 6 years ago | (#23456534)

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 Microsoft Notepad fan boy (in fact, I hate the thing), but I would expect Notepad to win hands down in that contest.

And every year, I would redo the contest, but I would add one more handicap to the team in the same room using notepad. I'd tie their hands together, so they would be forced to type with their little pinky finger. I would make their room airtight and I'd cut off the oxygen going into their room. And if the Notepad team does survive my challenge, and win again of course, I'd call my methodology the pinky finger no-oxygen method, so I could slap a patent on it, and compete directly against "UNA".

Rules [n-brain.net]
# For both the Dragon and the Hydra challenges, developers must collaborate on a single solution. In the Dragon challenge, the developers collaborate through email and the shared version control repository. In the Hydra challenge, developers collaborate in real-time using UNA itself.

Re:Hydra by Two Noses? (1)

FrozenFOXX (1048276) | more than 6 years ago | (#23461390)

Agreed. Some people collaborate with each other, the rest of us just clobber each other.

SubEthaEdit (4, Interesting)

Caste11an (898046) | more than 6 years ago | (#23452538)

I've used SubEthaEdit [codingmonkeys.de] for years for this purpose.

Re:SubEthaEdit (1, Insightful)

otomo_1001 (22925) | more than 6 years ago | (#23452678)

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

Jesus_666 (702802) | more than 6 years ago | (#23452880)

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.

Re:SubEthaEdit (1)

nuzak (959558) | more than 6 years ago | (#23452984)

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.

screen. (1)

FooAtWFU (699187) | more than 6 years ago | (#23454324)

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

Re:screen. (1)

nacturation (646836) | more than 6 years ago | (#23455412)

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?
 

Re:screen. (1)

FooAtWFU (699187) | more than 6 years ago | (#23456488)

Such matters are silly fripperies (and we don't need 'em :P)

Re:screen. (1)

totally bogus dude (1040246) | more than 6 years ago | (#23458478)

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 (if that's even a benefit)?

I think we can assume... (1)

BJH (11355) | more than 6 years ago | (#23452586)

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

Re:I think we can assume... (1)

gbjbaanb (229885) | more than 6 years ago | (#23452686)

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.

Re:I think we can assume... (1)

Crazy Taco (1083423) | more than 6 years ago | (#23453716)

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 engineering class (my junior year of college) made a collaborative software editor for Eclipse as one of their TWO projects for the semester. This just isn't that hard, or that big a deal...

That's good for RealityTV, but.. (4, Insightful)

Cyberax (705495) | more than 6 years ago | (#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'.

Re:That's good for RealityTV, but.. (0)

Anonymous Coward | more than 6 years ago | (#23453680)

exactly, this sort of thing might be OK for a smaller development team, say less than 5 people. It might even be ok for an open source team, but I don't see something like this taking root anywhere else.

my main problem with the tool is the use of the graphics and UI. First off, the images they use of weird looking aliens is a complete turn off for me. Maybe your stereotypical hardcore sci-fi geek programmer material, but not everyone else. Secondly, the built in transparent menu stuff just seemed awkward and obtrusive (course I imagine it can be turned off). Sorry, but I'll stick with eclipse/netbeans/etc.

Re:That's good for RealityTV, but.. (1)

Have Brain Will Rent (1031664) | more than 6 years ago | (#23455172)

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 the wrong problem.

Dragon for the Win (5, Funny)

antirelic (1030688) | more than 6 years ago | (#23452660)

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

Re:Dragon for the Win (0)

Anonymous Coward | more than 6 years ago | (#23453274)

Hydras are clearly better than Dragons. They have the same skill factor and a better power factor.
They recruit in more places that are easier to get to. Their terrain specialties are about a wash.
The only thing really going for Dragons is that they can recruit Colossus.

Re:Dragon for the Win (1)

2short (466733) | more than 6 years ago | (#23454938)

I'm breaking my usual rule by replying to an AC, but it's exciting that someone somewhere jumped to the same connection as me:

"Hydras are clearly better than Dragons. They have the same skill factor and a better power factor.
They recruit in more places that are easier to get to. Their terrain specialties are about a wash.
The only thing really going for Dragons is that they can recruit Colossus."

Sure, toe-to-toe in battle Hydras are marginally better than Dragons, but you neglect the advantage of flying, which has got to be worth at least 1 power.

If you pursue a strictly focussed development goal, getting them is not that much different, baring interference, so it really depends on the aggressiveness of your opponents. You could call the terrain bonuses a wash, but being able to live in the Volcano is just cool.

But really, being able to recruit Colossus (Colossi?) is the main thing, but that's huge. Essential if you really want to build the uber-stack.

Re:Dragon for the Win (1)

Workaphobia (931620) | more than 6 years ago | (#23454788)

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.

Re:Dragon for the Win (1)

RockModeNick (617483) | more than 6 years ago | (#23455008)

Unless you asshat opponent has probes EVERYWHERE.

Re:Dragon for the Win (1)

RockModeNick (617483) | more than 6 years ago | (#23455096)

observers, rather.

Re:Dragon for the Win (1)

turing_m (1030530) | more than 6 years ago | (#23460226)

The one exception is where all hexes surrounding the hydra are filled with dragons.

Re:Dragon for the Win (1)

Scrab (573004) | more than 6 years ago | (#23461776)

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

Just had a call from 1989. They want their THAC0 back.. ;)

Ever been attacked by a Hydra? (1)

Dareth (47614) | more than 6 years ago | (#23463608)

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't have any more heads!

OBTW, Fast != Good Code (2, Interesting)

FurtiveGlancer (1274746) | more than 6 years ago | (#23452664)

I wonder if there will be a quality review of the code and comments before they declare a winner?

Re:OBTW, Fast != Good Code (0)

Anonymous Coward | more than 6 years ago | (#23452752)

Whats a comment?

No Kidding (0)

Anonymous Coward | more than 6 years ago | (#23454032)

The only way the hydra even gets anywhere is if all of the heads know, and agree on, which way they are going ahead of time. In other words, unless they work well together or have a clear process for deciding direction and lack egomaniacal crybabies, they will have a hard time changing direction.

Now there's an idea! (5, Funny)

consonant (896763) | more than 6 years ago | (#23452692)

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

Re:Now there's an idea! (1)

dodobh (65811) | more than 6 years ago | (#23454636)

The first would be C++ vs Java, with the challenge involving fork and dropping privileges multiple times.

Re:Now there's an idea! (1)

SoulRider (148285) | more than 6 years ago | (#23462404)

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

Developers suffer from interruptions (4, Interesting)

Anonymous Coward | more than 6 years ago | (#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:Developers suffer from interruptions (2, Insightful)

nuzak (959558) | more than 6 years ago | (#23453012)

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

Re:Developers suffer from interruptions (1)

mcvos (645701) | more than 6 years ago | (#23462036)

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

Re:Developers suffer from interruptions (4, Informative)

turbidostato (878842) | more than 6 years ago | (#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.

Let me explain with smaller words (0)

Anonymous Coward | more than 6 years ago | (#23454436)

There is much evidence that collaboration does not improve developer productivity.

It isn't that bringing newcomers up to speed delays progress. The newcomers bog things down no matter how fast they come up to speed. If you have read the book, read it again.

Re:Let me explain with smaller words (1)

turbidostato (878842) | more than 6 years ago | (#23455786)

"There is much evidence that collaboration does not improve developer productivity."

Surely it doesn't, so what? How cares about developer productivity, except for the developer himself? Everybody else is interested about *project* productivity. What is the interest of a "full productivity" environment (i.e.: a single guru, jack-of-all-trades that warranties the lowest man-hour count for a project) if the target date is missed by three years? I very much will use a five-people team with an overall productivity of only 80% giving me a time-to market of one year than a single-developer show that will retain the product four years. In fact, the very interesting point is being able to find on a repeteable manner the "sweet spot" where you can optimize, at the same time, man hours (money) and time-to-market.

"It isn't that bringing newcomers up to speed delays progress.

Yes it is.

"The newcomers bog things down no matter how fast they come up to speed."

Bullshit. Just add in proper time ie. a database expert to a team that has noone for a three-tier project and you will see how things do *not* bog down.

"If you have read the book, read it again."

I read it, thanks, and I'm quite aware about what the differences are between partionable and non-partitionable tasks (the bearing of a child takes nine months, no matter how many women are assigned) as I'm about how communication complexities can grow exponentially.

Still, it doesn't mean that bringing more heads to a project will delay it. It means that trying to partition what's unpartitionable (or, in other words, trying to parallelize what is serial in nature) won't give you earlier results, and it means that bringing new heads to an already delayed project will add a further delay that it is function of the bringing to speed effort (both technically-wise and due to integration on the team) and it means that adding one man-month more to the project won't allow for the project to be finished one month earlier, NOT that it won't be finished earlier.

Maybe you should re-read the book too, trying this time to *understand* the overall concepts, not only the sentences.

Re:Developers suffer from interruptions (1)

arevos (659374) | more than 6 years ago | (#23457178)

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 outperform a team of 60.

Re:Developers suffer from interruptions (1)

turbidostato (878842) | more than 6 years ago | (#23469206)

"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 beyond that adding more "horsepower" won't lead to an earlier finish (and probably it will make it later). The point is needed, because as long as there are "communication islands" the problem won't appear. And, as the author states himself in its 20-year revision, there can be practices (like OO programming) that can heavily reduce communication needs thus making room for more people.

"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 outperform a team of 60."

That's true, once you add the "*if* some constraints appear (like heavy intercommunication dependance) there will be a point that...". Not to say that *all* inter-communication channels can be closed (or even that it's benefitial trying to close them), but they can be diminished, and by doing so, you are certainly killing (to a point) the mythical man-month.

Re:Developers suffer from interruptions (1)

WhoCantTakeAJoke (1257240) | more than 6 years ago | (#23454486)

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.

Collaborative programming is not new (3, Informative)

njcoder (657816) | more than 6 years ago | (#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.

What vs. what? (1)

Haeleth (414428) | more than 6 years ago | (#23453024)

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?

Re:What vs. what? (1)

pohl (872) | more than 6 years ago | (#23453150)

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:What vs. what? (0)

Anonymous Coward | more than 6 years ago | (#23453162)

Think about it in terms of the number of heads:

Dragon = 1
Hydra = n (where n > 1)

Now apply that to the number of programmers working in tandem.

Re:What vs. what? (0)

Anonymous Coward | more than 6 years ago | (#23453212)

"Hydra" is development using web-ex and irc, whereas "Dragon" is the old tired (according to n-brain anyhow) method of coding where you concentrate.

In the long run, I would imagine most of the people who end up being forced to use this product by their buzz-word driven development management will avoid the concurrent editing feature like the plague.

Re:What vs. what? (2, Funny)

Mr. Bad Example (31092) | more than 6 years ago | (#23453278)

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

Not solving anything (1)

zensonic (82242) | more than 6 years ago | (#23453262)

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 same piece of code is actually less efficient than having only one person writing it in the first place.


Programming is actually quite a lot like amdahls law: you need time to break the task down into independt task that can be parallized. That is called modular design and is an old topic. A fancy editor is not magically going to speed up development.

Re:Not solving anything (1)

Antique Geekmeister (740220) | more than 6 years ago | (#23453296)

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.

And then there's the third theory: (4, Funny)

Antique Geekmeister (740220) | more than 6 years ago | (#23453276)

Theo de Raadt.

Starcraft Reference (2, Funny)

sadgoblin (1269500) | more than 6 years ago | (#23453322)

dragoon > hydra

Re:Starcraft Reference (1)

chillax137 (612431) | more than 6 years ago | (#23453794)

depends on the range upgrades!

Re:Starcraft Reference (1)

smellotron (1039250) | more than 6 years ago | (#23457470)

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

I want to compete (4, Funny)

Ilan Volow (539597) | more than 6 years ago | (#23453776)

Simply for the hot groupies who will obviously throw their bodies at me when I win.

Re:I want to compete (0)

Anonymous Coward | more than 6 years ago | (#23459008)

this is not Moto GP and you are not Valentino De Rossi

Nothing to See Here, Please Move On (3, Insightful)

crunchy_one (1047426) | more than 6 years ago | (#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.

Agreed (0)

Anonymous Coward | more than 6 years ago | (#23459414)

From their FAQ:

Why can't I use some other language than Java?

In this competition, we are looking at real-time collaborative development versus traditional development. If we allowed developers to compete in any language, then we would introduce bias into our study â" developers who chose a higher-level language would perform better than developers who chose a lower-level language.

Lower level languages lend themselves to collaborative development, because there's more boilerplate code to write and shove around in an IDE. By forcing the competitors to write in Java they bias the study towards "Hydra," which is clearly intentional.

Editing the same file (1)

polyex (736819) | more than 6 years ago | (#23454046)

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 twice as fast as one. Just the fact they are using terms like Hydra and Dragon make it sound stupid.In my experience developers have so much on their plate and are understaffed as it is, to spend time reviewing others code just adds to the pressure cooker. Why not let the developers decide what would be best at the particular moment rather within the particular problem domain (not outlined in this "contest" than trying to find one solution that is supposed to work in all circumstances (Hydra VS Dragon) as if one is "better"?

World's Finest? (0)

Anonymous Coward | more than 6 years ago | (#23454152)

How do you get the world's finest developers when the reward for winning is smaller than the paycheck of a typical good developer (at least in the US)?

Re:World's Finest? (1)

YttriumOxide (837412) | more than 6 years ago | (#23454476)

How do you get the world's finest developers when the reward for winning is smaller than the paycheck of a typical good developer (at least in the US)?

According to TFA, the competition is 2 days, and the prize is $7000 (in stuff, not actual cash)

Does a typical good developer in the US REALLY get $3500 a day? Somehow I doubt it... (although if it's true, I'm packing up my bags and moving there tomorrow!)

Re:World's Finest? (1)

MasterRat (1223392) | more than 6 years ago | (#23462606)

More importantly, look at the qualifying and qualification challenge pages on the website. Please explain to me how these pages qualify the worlds's finest developers. Development is significantly more than the ability to write an application using only the Java 5 "libraries" (their word, not mine) and to do so in a single source code file. Oh, and you have to have a high speed internet connection, which is obviously a bona fide occupational requirement for membership in the "world's finest developer" club. Personally, anybody that does anything in a single Java source code file of the complexity described should be barred from writing Java code ever again. IMHO, the competion should be restated to be using "anybody we can find, that has a high speed connection, is willing to record everything, and doesn't mind hacking till the cows come home."

Starcraft? (1)

yayotters (833158) | more than 6 years ago | (#23454336)

Dragoon vs Hydra anyone?
:]

Re:Starcraft? (1)

yayotters (833158) | more than 6 years ago | (#23454398)

oops...Missed the other response.
God I suck.

Java (0)

Anonymous Coward | more than 6 years ago | (#23454912)

Why am I not surprised that both Tour examples [n-brain.net] are based on Java ?

Invalid competition (4, Informative)

PipingSnail (1112161) | more than 6 years ago | (#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.

And teh winner... (1)

JAlexoi (1085785) | more than 6 years ago | (#23455450)

Will be a Russian mythical creature, that is a cross between a hydra and a dragon!

Re: With a laser on his head (1)

Douglas Goodall (992917) | more than 6 years ago | (#23460124)

In Soviet Russia...

Projector (1)

blaster151 (874280) | more than 6 years ago | (#23456286)

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

like the man said..it depends (0)

Anonymous Coward | more than 6 years ago | (#23456956)

I have seen several groups over the years. The success of beating one brain over two depends on several factors. How smart the individual is compared to the team, quality of the group vs individual, and speed of work (if timed). However the team has several possible draw back depending on these personalities (could be more): dedicated worker, smart worker, the complainer, the loafer, the team player, the dumb worker, and the joker. While the show might limit how the teams are constructed; it might be better to get the extreme personalities on the show to see how a group fails in respect to the individual; its worth noting that the individual might be part of these personalities that might cause him or her to fail too. So as the man said, it all depends.

Ewww Java (1)

stephentyrone (664894) | more than 6 years ago | (#23458424)

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.

Re:Ewww Java (1)

mcvos (645701) | more than 6 years ago | (#23462074)

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.

I'm sure .. (0)

Anonymous Coward | more than 6 years ago | (#23464300)

.. you meant "me, for example" when you said "many of the world's finest software developers" :)

Seriously, knowing Java and using Java are two different things. Java is like a prechewed, canned Filet Mignon - sure it's nutritious, but it *is* crap nonetheless compared to the real thing.

Re:I'm sure .. (1)

mcvos (645701) | more than 6 years ago | (#23491260)

.. you meant "me, for example" when you said "many of the world's finest software developers" :)
No, I'm still stuck using Java 1.4, I'm afraid. I'm looking for a cool Ruby job, though, so let me know if you've got anything.

Seriously, knowing Java and using Java are two different things. Java is like a prechewed, canned Filet Mignon - sure it's nutritious, but it *is* crap nonetheless compared to the real thing.
No, Java is perfectly fine for what it's intended for. And for applications, it's certainly a lot better than C++, and for big web applications, it's better than PHP and VB. Java was a gigantic step forward 10 years ago, but now it got stuck in the overly complicated enterprise web service stuff.

Perhaps it's time for another step forward. It's been 10 years, after all.

Re:Ewww Java (1)

SoulRider (148285) | more than 6 years ago | (#23462340)

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 dozen middle managers that would watch that.

CM, CM, CM folks (1)

recharged95 (782975) | more than 6 years ago | (#23458718)

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.

-please ignore...- (0)

Anonymous Coward | more than 5 years ago | (#23514824)

this is to undo my moderations.... does it work anon? lets see...
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?