Slashdot Mirror
The Importance of Collaborative Development
Eugene Eric Kim writes: "A few months ago, I wrote an essay entitled, "A Manifesto for
Collaborative Tools," outlining a vision for how we can and should be
making collaborative tools more interoperable. The article was
published in the May issue of Dr. Dobb's Journal and is now available
on the web." This manifesto is a good one, particularly if you aren't as a familiar with Doug Engelbart as you should be. There's also some interesting links to learn more about the Semantic Web, and social networks, well worth checking out as well.
I don't know about your workplace environment, but my company has locked down shares and peering due to the fact that this an infection vector.
I think peering/collaboration is the way to go, but this is becoming increasingly difficult thanks to the lax default permissions that was inside windows (yeah I'm not a windows admin, and the default share was always set at world full access). The knee jerk reaction was to disallow *all* peer/sharing.
I'll probably get ripped and modded to hell for this but I was looking forward to the "hive" type setups that MS was proposing for peering(for work this would be a godsend, I wouldn't do this at home tho). My concern was their security model.
Just how in the hell can this be done when virii explicitly target this functionality? CVS / Subversion is not an answer for business/end users...
B
Having more than one person on a project helps
a whole lot. Especially when you have people
with different skills that are all good coders.
I'm working on a "hobby" project right now, where
we have 1 person that does alot of the major coding
because he is really good with the catagory the
software falls into. Another person codes the
UIs, and I do alot of other work, planning and
support (I coded the network classes for our
project, for example). Things are working quite
well, it's been really nice.
Is there actually any proposal as to how this is done?
The manifesto makes grand claims about unifying our collaborative language, but totally understates how difficult this is. The problem usually is that we just do not have a solid model of what can and cannot be done, and we likely never will.
The author pointed at SQL as an incredibly important standard for how data is handled. However, relational databases are relatively simple. We know most everything they can do, so we can define it. And, even, with that, databases are not entirely standard. Most databases have their own little features, often not in the standard.
Look at another good example: filesystem structure. Despite how well defined the Filesystem Hierarchy Standard is, distros still tend to be non-compliant. It's an incredibly simple system, and we can't even reliably follow it. Is aiming at standardized interfaces between collaborative applications truly reasonable?
Hopefully, a few things can be standardized, as they are recognized as being universally useful. Some basically are. For example, e-mail is e-mail. There's not too much more to it. Maybe we can slowly define those things which we understand and see the importance for, but moving much beyond that is likely infeasible.
In my experience, if I'm paired with someone good, and either one of us is in the zone, neither of us speaks. It's just a matter of being polite - when I'm not at the wheel I have time to read the code, and try not to talk unless the other programmer is moving on with something obviously unfinished or flawed. It's like a constant code review, but it's a lot more interesting to read the code as it's written.
Powered by Web3.5 RC 2
You're certainly not the only one. I'm not one of those, though -- I often find it useful to speak aloud about what I am doing to help me understand a problem better. The thing is that not everyone can structure their thought process well enough to expose it completely throughout -- people have to understand you can't do it, but you have to understand that some can, too. And when they can, it's a great tool, certainly.
However, if you pair up two coders who don't have an about equal level of skill, then you're wasting potential -- it becomes a tutoring session, but the both cannot come fully into their own, because one is straining to understand the model while the other is held down to trying to chew everything down for the first.
I fail to see, though, where paired programming comes into the discussion? I couldn't see any mention of it in the article...
I've been working on a tool for a while which may be of interest in this discussion. The site is at www.forcomment.com.
The concept is that a single user tends to create a document (or part of one) and usually then e-mails it out to others for comment. I allow the user to upload the document to our site, convert it from native format to HTML (where needed), invite those required to comment, and allow discussions to happen at the sentence level in the document. It should also work from all browsers. It is being used successfully by several UK universities now for Europe-wide projects.
I've come across other ways of doing this before, but they all seem to be embedded into proprietary document formats or editors, so requiring that all parties collaborating have the same editing software.