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
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.
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"?
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.
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!)
My book about LSD and Self-Discovery
Also on facebook as: DroppingAcidDaleBewan
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
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!
"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.
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 . . .
rid us of the problems with resolving, merging, and hopefully an ease to file versioning.
In Soviet Russia...
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."
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"Perhaps it's time for another step forward. It's been 10 years, after all.