Slashdot Mirror
Dragon vs. Hydra - Competing Development Styles
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.
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.
Invenio via vel creo
I've used SubEthaEdit for years for this purpose.
...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.
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'.
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...
20th century Marxism is not progress...
I wonder if there will be a quality review of the code and comments before they declare a winner?
Invenio via vel creo
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
[Slashdot Comments We Liked]
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.
Invenio via vel creo
Whats a comment?
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
"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
The best development model I can think of is Linux. Everyone works on their own thing and submits it when it is ready.
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.
Open Source Java DAO Generator
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?
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.
Thomas S. Iversen
Theo de Raadt.
dragoon > hydra
Simply for the hot groupies who will obviously throw their bodies at me when I win.
Ergonomica Auctorita Illico!
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.
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.
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"?
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)?
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".
The World Wide Web is dying. Soon, we shall have only the Internet.
Dragoon vs Hydra anyone?
:]
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.
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.
Invenio via vel creo
Why am I not surprised that both Tour examples are based on Java ?
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 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.
rid us of the problems with resolving, merging, and hopefully an ease to file versioning.
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.
In Soviet Russia...
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!
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
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?
.. 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.
this is to undo my moderations.... does it work anon? lets see...