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'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
Theo de Raadt.
> 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.
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.
Wow. Really. You publicly humiliate a person each week? What a management style! I think it's called being an asshole.
The tyrant will always find a pretext for his tyranny - Aesop
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.