Dragon vs. Hydra - Competing Development Styles 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.
Hydra by Two Noses? (Score:4, Insightful)
Re:Hydra by Two Noses? (Score:4, Insightful)
Forcing everyone in to the same paradigm is hard..
--Q
You Agree, Quarrel? (Score:4, Funny)
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)
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: (Score:1)
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! (Score:2)
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)
Re: (Score:2)
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: (Score:2)
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
Re: (Score:1)
Re: (Score:2)
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: (Score:2)
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 (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:1)
SubEthaEdit (Score:4, Interesting)
Re: (Score:2, Insightful)
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)
The company desperately tries to be cool, but like everyone who does that they fail. Horribly.
Re: (Score:2)
screen. (Score:2)
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: (Score:2)
Re: (Score:2)
Re: (Score:2)
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
I think we can assume... (Score:1)
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: (Score:2)
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: (Score:2)
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
That's good for RealityTV, but.. (Score:5, Insightful)
In 99% of situations you should just modularize your code to minimize conflicts, not try to make them 'nicer'.
Re: (Score:2)
Dragon for the Win (Score:5, Funny)
Wait... I'm gonna go read the summary quick...
Re: (Score:1)
"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, whi
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Ever been attacked by a Hydra? (Score:2)
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
OBTW, Fast != Good Code (Score:3, Interesting)
Now there's an idea! (Score:5, Funny)
"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: (Score:2)
Re: (Score:2)
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 (Score:4, Interesting)
"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)
Ergo, the fastest projects have nobody working on them.
I think Brooks might have been aiming at something more nuanced.
Re: (Score:2)
Ergo, the fastest projects have nobody working on them.
Ergo, every program can be reduced to one statement that doesn't work.
Re:Developers suffer from interruptions (Score:5, Informative)
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.
Re: (Score:2)
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 produc
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:1)
Collaborative programming is not new (Score:4, Informative)
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? (Score:2)
Anyone who understands the buzzwords care to cut the crap and explain what this is actually all about?
Re: (Score:2)
Re: (Score:3, Funny)
> 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 (Score:1)
Re: (Score:2)
And then there's the third theory: (Score:5, Funny)
Starcraft Reference (Score:1, Funny)
Re: (Score:2)
Re: (Score:2)
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 (Score:5, Funny)
Nothing to See Here, Please Move On (Score:3, Insightful)
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.
Editing the same file (Score:1)
Re: (Score:2)
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: (Score:1)
Invalid competition (Score:3, Informative)
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... (Score:1)
Re: With a laser on his head (Score:1)
Projector (Score:1)
Ewww Java (Score:2)
Re: (Score:2)
pretty much guarantees that none of "the world's finest software developers" will be involved in this competition.
Re: (Score:2)
.. 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: (Score:2)
CM, CM, CM folks (Score:2)
rid us of the problems with resolving, merging, and hopefully an ease to file versioning.