Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Programming Education Software IT Technology

The Importance of Collaborative Development 61

Posted by Hemos from the working-together-for-bettering-us-all dept.
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.
This discussion has been archived. No new comments can be posted.

The Importance of Collaborative Development More

The Importance of Collaborative Development

Comments Filter:
  • ...check out SemWebCentral [semwebcentral.org], which is a GForge [gforge.org] installation hosting a fair number of Semantic Web-related projects. There's even an OWL mode for Emacs! [semwebcentral.org]

    And there are also some tutorials and such-like [semwebcentral.org].
  • ...who absolutely positively -HATES- the idea of 'paired programming'? While I wholeheartedly agree with having lots of meetings and discussions during the design phase (requirements, functional spec, detailed design) and during the review phase (post mortem, code reviews) I feel that having two coders on one computer is extremely wasteful and unbelievably stressful.

    When I'm in the 'zone' I can't talk with somebody else, I can't verbalize why I'm writing a code fragment the way I am writing it without gett
    • Yes, you are the ONLY one :)

      Actually, I am a big fan of it, although why am I never paired with some brilliant supermodel?

      ___________________________

      I'm not a .sig, but I play one on TV
    • "While I wholeheartedly agree with having lots of meetings and discussions during the design phase (requirements, functional spec, detailed design) and during the review phase (post mortem, code reviews) I feel that having two coders on one computer is extremely wasteful and unbelievably stressful."

      Did I miss in the article where they said 2 coders on the same computer??? When they talk about colaboration they don't say 2 conders on a computer or people looking over your shoulder.

    • Re:Am I the only one... (Score:5, Insightful)

      by WeeBull ( 645243 ) on Monday April 12, 2004 @08:53AM (#8836751)
      I agree with your sentiments, but in my experience there's at least one more scenario where pair programming is benefitial - where neither coder A or coder B have any experience with the codebase in question. In cases like that, I've found it incredibly valuable to have someone to talk to and bounce ideas and suggestions off of while trying to figure out exactly what (nevermind how? or why?) a particular piece of code or sub-system does.

      Oh - and you're way off topic, btw. RTFA =)

    • When I'm in the 'zone' I can't talk with somebody else, I can't verbalize why I'm writing a code fragment the way I am writing it without getting yanked out of it.

      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

    • I HATE paired programming, but I have a contract in an XP cult^C^C^C^C shop right now so we are doing that, we are about as XP as it gets - stand up meetings, team design sessions, tunnel vision, paired programming, stories, tasks etc.

      One thing though is that being on a contract I don't really care about this whole thing that much, so if the company is paying for us to pair, why shouldn't we just take advantage of it and relax a bit?

    • (Score:0, Troll)

      Im going to have to agree... this article seemed like yet another big fluffy acedemic rant about what's wrong with computer software these days, without giving ANY practical new ideas.

      I mean, look at his roadmap at the end: Be people-centric? Collaborate? Use standards? Keep improving? Is that supposed to be profound? I doubt its even correct!

      Its neither necessary nor sufficient for developers to do any of the above and make great software. Is 'C' people-centric? How much GREAT softwar

    • 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
    • I know this is Slashdot, but posters usually manage to get somewhere within spitting distance of the topic even when they haven't RTFA. Did you even bother to read the precis, or are you just having a knee-jerk reaction to the word "collaborative" in the title?

  • Eigenpolls (Score:4, Informative)

    by AeiwiMaster ( 20560 ) on Monday April 12, 2004 @08:46AM (#8836721)
    I have made a Collaborative Tools
    which i call eigenpolls [all-technology.com]

    Check it out.
    • I am now working on an OSS project with a lot of these ideas in mind.

      Discourse District [huji.ac.il]
      A dynamic repository for community writings, a mirror, mapping the writing community.

      (the link above points to an abstract, the link to the system is at the bottom)

      basically it is a wiki adaptation [sourceforge.net] with touchgraph [sourceforge.net] interface, that is meant to be a community utilized concept map.
      Born out of a need to define the Complexity community, its scope, and the fact that no one person could define it , since everybody
      • Once I got over the "neato" factor of touchgraph, I found myself wondering "how on earth could anyone really find this useful?"

        It pops and jiggles around, thus being incredibly distracting. Aside from not being much of a help to the typical ADD-R afflicted geek type, it wastes a lot of time and space doing so until it "settles" down.

        It has no history. No way to go "back". No way to reference the history, with even a list, let alone a tree.

        It has no spatial organization (other than essentially "random"
        • Thanks for your comments.
          Like I said , it is WIP, (and probably will keep being.)

          History, good idea, easy to implement, didn't occur to me, till you brought it up, can do, definitely on my to do list

          spatial organization - also a good idea, but i have'nt decided how it should be, i thought of adding 'gravity', and 'weights' so 'heavier' nodes would tend to be below their parents, pushing the others up or something., i don't know yet

          "glue to backgroud" good idea, can do , will think about it.

          as for

          • Huh, I wasn't aware you were the author of touchgraph -- I regret the snideness, but I have seen enough navigational metaphors in my day, each one coming with enough evangalism that it was cultlike (see gelerntner's "streams" and fans of pie menus for some more case studies). Nonetheless, I do apologize for the tone.

            Snapping instantly to the final location is probably jarring, but might be ideal in a few cases. It sounds like a configuration option to me, to only display n steps of motion, plus the optio
            • No , i am not the author of touch graph, sorry if it came out that way.
              Alex Shapiro is
              I just modified the code to suit my needs.
              what i did write was the attached wiki and the interfaces, both ways

              Anyway, there was no cynicism in my previous post.
              I am truely thankful for your comments AND the accompannying tone.
              I'd gladly trade any amount of politeness for a like amount of truth.
              ---
              OT
              ---
              It (being truthful at the cost of being polite/PC) would make life a lot more simple most of the time,
              and in

  • Collaborative Work vis a vis locked down (Score:5, Interesting)

    by beacher ( 82033 ) on Monday April 12, 2004 @08:47AM (#8836726) Homepage
    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

  • people-centric (Score:4, Insightful)

    by millahtime ( 710421 ) on Monday April 12, 2004 @08:50AM (#8836737) Homepage Journal
    This is one of the most important things in creating any product. I have seen in software and engineering, programs and products created that were technically really cool but didn't fulfil what the "people" wanted.

    Creating applications that are people-centric are key. They can make or break a product. I use an app that has a few bigt bugs but it was designed to be people-centric so I still love it. It was coded horribly, has crashed for some dumb reasons but how it was designed is great. (A note, I am working with the author to iron out those bugs)

  • comments (Score:3, Interesting)

    by Hangin10 ( 704729 ) on Monday April 12, 2004 @08:51AM (#8836739)
    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.

  • That's All Fine and Good, But... (Score:5, Interesting)

    by Jameth ( 664111 ) on Monday April 12, 2004 @08:53AM (#8836748)
    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.
    • However, relational databases are relatively simple.

      But that's the whole point--Now it's simple. When I'm doing something that needs a relational database, I don't have to re-invent one. There might be fiddly details with plumbing and which one to use, but during design, I can draw a relational database box on the whiteboard without worrying too much about what's inside it. If I want to connect a bunch of tables, select what I want, sort them a particular way, it's there.

      • Yes, and collaboration is not simple. Hence the problem.

        Databases have advanced very little with time. Collaboration methods change day-to-day. Sometimes the methods change due to whim, sometimes due to fashion, and sometimes due to technology. Whatever the reason, collaboration methods are hard to nail down reliably.

    • The proposal is at the end of the article, in the "Roadmap for the Future" section [blueoxen.org]...
      I question whether you made it that far before deciding to rant.

      To Summarize:

      • Be people-centric
      • Be willing to collaborate
      • Create shared language - most important and difficult IMHO
      • Keep improving

  • Help us to improve MediaWiki (Score:5, Informative)

    by Eloquence ( 144160 ) on Monday April 12, 2004 @08:56AM (#8836762)
    MediaWiki [mediawiki.org] is the open source software running Wikipedia [wikipedia.org], Wikibooks [wikibooks.org], Disinfopedia [disinfopedia.org], the MozillaZine Knowledgebase [mozillazine.org], and many other wikis [wikipedia.org]. Eugene is correct in noting that we need to work together in improving our collaborative tools. Wiki technology is one of them. Use it for your open source software documentation. Add a link to your documentation wiki to the software's "Help" menu, so that your users are encouraged to fill the gaps.

    MediaWiki in particular implements many ideas that were already envisioned by Ted Nelson and Doug Engelbart. It does show backlinks, but perhaps more importantly, it also allows dynamic inclusion of any page in the current development version [wikipedia.org]. For example, you could have a header and footer in your documentation that is the same for every page. What's more, you can add parameters to these templates to dynamically search and replace patterns of text in the template before transcluding it. This will allow us to replace the currently statically hacked Wikipedia infoboxes [wikipedia.org] with dynamically included and parametrized templates, for example. One long term feature that might be worth hacking on top of this would be transclusion of labeled sections from another page, or interwiki transclusion.

    Check out the current feature list [wikipedia.org] and the development roadmap [wikipedia.org]. Subscribe to wikitech-l [wikipedia.org] to help us in improving the software. In true wiki spirit, we are fairly liberal at handing out CVS access (over 40 developers with CVS access at present), so please do ask if you want to work on a larger project.

    There are many other wiki engines that are worth working on, such as TWiki [twiki.org] and MoinMoin [sourceforge.net]. Their main deficiency, in my opinion, is that they do rely primarily on the traditional wiki link pattern of CamelCase [wikipedia.org], which is nice for geeks but very ugly for everyone else, and also useless for search engines. MediaWiki uses [[free links]] instead, which are harder to type, but look just like normal links to the reader. Still, working on any other wiki engine is a lot better than starting yet another one.

    A collaborative tool which is badly needed is a free software clone of SubEthaEdit [codingmonkeys.de]. Combine wikis with real-time editing and the fun really begins. I imagine something like that might be hackable on top of a powerful graphical editor like Kate [kde.org]. For now WebDAV-support for MediaWiki would also be very cool, as Kate/KDE already supports editing WebDAV resources. So many worthwhile hacks, so little time.

    This is an area where open source coders can make a big difference while corporations are still bewildered by the fact that open wikis can produce useful content. So please, let's work together on these tools.

    • Re:Help us to improve MediaWiki (Score:5, Insightful)

      by Jameth ( 664111 ) on Monday April 12, 2004 @09:07AM (#8836808)
      What I don't get is why the open source groupware projects aren't integrating wikis. It has been solidly proven that wikis can be powerful in certain situations. And, in a collaborative environment, there is virtually no alternative solution for what a wiki provides.

      Also, if a good groupware system integrated an editor into the client and supported a slightly more extensive set of tags, this could result in easy to edit, good-looking documents made collaboratively.

      Why are so many open source projects so densely certain that they must imitate proprietary crap?
      • although open source is prefered for it's free nature, imagine what would happen if MSoft went to open source help. They would lose money hosting it, compared to now when they charge an arm and a leg, or blame the problem on something else.

        In keeping with the true nature of the article, open sourced collaberative works tend to not be associated with the product or actual use of the works, but instead with the hard core users or people who are interesting in helping/developing on their own time. Right now
      • You may be interested in the WikiGateway project.

        http://interwiki.sourceforge.net/cgi-bin/wiki.p l ?W ikiGateway

        WikiGateway is a library of functions which allows you to act as a client to a wiki website, executing operations like getPage, putPage, and getRecentChanges. WikiGateway translates your requests into the idiosyncratic HTML form interfaces of various popular wiki servers. The wiki which you are accessing doesn't have to know about WikiGateway; it sees you as just another user. Basically, WikiGate
    • Most Wikis I have used support [[free links]] if you really want to use them, but for QuickAndDirty stuff CamelCase is fast and easy. And MediaWiki has its own (IMHO) bad design decisions, too: the ability to include arbitary HTML means that you're stuck with HTML as your only output format.
  • Buzzsaw is an amazing piece of software that many companies in the A/E industry use. It's not free, but if you're rolling you own it's a good place to get some ideas.

    Autodesk Buzzsaw [autodesk.com]

  • File Systems (Score:3, Informative)

    by akaina ( 472254 ) * on Monday April 12, 2004 @09:04AM (#8836792) Journal

    A number of applications (both commercial and open source) claim to solve the document-sharing problem, and yet, the predominant method for sharing files is to email them back and forth. This is the computational equivalent of sneakernet. If the tools that purport to solve this problem are good, why aren't we using them?


    Doing everything via a share would require a massive amount of permission adjustments that users just can't handle easily. Not to mention, file systems are only useful when two users are on the same network. An internet filesystem is simply not practicle enough to use on a daily basis. This may be one place where Internet2 might show us what's possible.
    • Internet filesystems work fine, if people bother to make them. The largest barrier is that most internet providers want to block everything under the sun, so nothing is ubiquitous.

      If everyone could have an sftp server, this would all be much easier. Just tell a friend or co-worker a password, and things are shared. Presto! Problem solved!

      As far as organization when you need to share with multiple people, well there's nothing preventing an sftp server from having multiple repositories and having different
  • My company's products [networkinference.com] specialize in the semantic web and ontologies. They were born out of a project at University of Manchester in England.

  • This morning I was... (Score:4, Funny)

    by BigGerman ( 541312 ) on Monday April 12, 2004 @09:26AM (#8836904)
    ...reading this very article over breakfast and I was thinking: why something like this is not discussed on Slashdot instead of the recent crap!

  • Document Creation Tools Need To Be Fixed (Score:5, Insightful)

    by theManInTheYellowHat ( 451261 ) on Monday April 12, 2004 @09:49AM (#8837053)
    The average user needs to be able to create the docs and the tools need to do the colaboration. It has to happen way before the the save-as menu option. It also needs to happen with out the users even knowing it is happening.

    I also think that the whole "document as a file" scheme needs to go away. The printed copy needs to have watermarked inside it the version and date it was created / printed. But the document is an ever changing entity that should be accessable and modified but not saved as a file. As soon as someone has a portable, editable file, the whole system is broken. Just like the floppy breaks the network.

    CVS et al. needs to be done at some level so that the user never even knows it is happening. I believe that the whole co-laboration methods that we have currently are great for programers and techies but the average user is still shaking their heads in confusion. Just like what the average user is thinking about public key encryption.
  • I just found out about this software yesterday on Slashdot. No one has mentioned it yet. It looks like some excellent software built with standards and interoperability in mind. Unfortunately with products like Microsofts Sharepoint focusing on... well... Microsofts bottom line interoperability may not be something easy to achieve.
  • This manifesto is a good one, particularly if you aren't as a familiar with Doug Engelbart as you should be.

    So...if you're familiar with Doug Engelbart, the manifesto is not good?

    Is that right? I have to dig deep for my 9th grade geometry skills.

    If not familiar, then good. So it follows that if not good, then familiar. Hmmm, I guess I didn't get it right. Still, the sentence is an odd one.
  • I am sure "collaborative software" as a topic has been discussed much on /. but is there a good way to get to these related forums for people who just visited this one?
    This would be an enhancement along the spirit of the article being discussed.

  • 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 [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 b

    • 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.

      How is this different from a wiki?

      • Re:Another collaboration tool (Score:4, Interesting)

        by ka9dgx ( 72702 ) * on Monday April 12, 2004 @03:54PM (#8840629) Homepage Journal
        It appears to be different from a Wiki in that comments are a separate layer from the base document. One of my big complaints about HTML is that it doesn't allow MarkUp, it just forces you to merge tags into an existing document instead.

        By having a set of Markup layers, gets much easier to see and manage comments, etc. Ideally, you should be able to simply toggle each layer of markup on and off, just like a mutli-layer image in PhotoShop or Paint Shop Pro.

        Some day we'll get real Hypertext, but we're defintely not there yet, and XML isn't it either.

        --Mike--

  • Hey, I know that name.

    He should've gotten a C programmer to collaborate with him on cgihtml.a... because he obviously can't write stable code all by himself.
  • I thoroughly enjoyed the article, and felt it hit the nail on the head on a number of issues. It's very useful to step back and look at the big picture and try to imagine where we are heading. This is truly Stuff that Matters.

    That said, I feel disappointed at the apparent lack of interest among /. readers. While a story about the latest Microsoft faux pas might generate 600 or more comments, an article as articulate and thought-provoking as this has drawn, at time of writing, a paltry 40 or so. Seems we do
  • The biggest missing feature is real, honest to goodness markup. You know it, instinctively, and here's how to use it with todays technology.
    • Print this article and comments
    • Mark up the paper with a pencil, crayon, yellow highlighter, etc.
    • ponder how anyone else is going to see an internet accessible copy of your markup layer.

    You can markup a copy of the document, but you can't do something as trivial as "link to characters 314-395 of document URL://whatever". If you want markup, you have to have write

Slashdot Top Deals

I have hardly ever known a mathematician who was capable of reasoning. -- Plato

Close