CXO

Commandments for Distributed Collaborative Development

Independent software development consultant Chip Camden spends much of his day worrying about Distributed Collaborative Development. These are the DCD rules he has learned throughout the years.

As an independent software development consultant who works mostly from home, I spend a large portion of my day worried about DCD. No, I don't mean Data Carrier Detect (I stopped using dial-up more than a decade ago), nor do I follow Dead Can Dance (that band split up in 1998). I'm talking about Distributed Collaborative Development: software engineering that defies the unities of time, place, action, and project management.

I've been doing this sort of work since I began consulting in 1991 — over a 9600-baud modem back then, and across the Internet today. Nobody ever handed me a "DCD for Dummies" book — my clients and I discovered the rules as we went along. Out of the goodness of my heart (and because I like playing Moses), here are 10 commandments for DCD, carved in the hard tablets of experience.

1. There shall be only one authoritative repository of source code. Nothing leads to more needless wheel-spinning than splitting off a version of the source for developing a feature that will eventually need to merge into the main source. Rather than creating a separate copy, use the power of your version control system of choice to branch and merge specific files as needed. This brings us to the second commandment.

2. Thou shalt use version control in all of thy projects. No matter how small or how prototypical the project, version control software is your friend. It not only prevents developers from walking on each other's work, it also documents the project history and acts as a layer of backup. For DCD, you need an option that works well over long distances. A traditional VCS repo on a shared drive over VPN will add many hours to a project of just waiting for archive access. You need something designed for distributed work, like Mercurial or Git. These products allow you to clone a local repository that you can periodically sync with the central repo — minimizing the bandwidth required to do intensive development. That also encourages frequent commits, which is a good practice for when you have to backtrack.

3. Thou shalt not kill the build. Don't push changes to the central repo until you're reasonably sure it isn't going to cause grief for your other team members. If the project gets ported to Windows, Unix, and OpenVMS, then you'd better test your changes on those platforms first. If you can't easily do that (waves hand for OpenVMS), then at least review the code with that platform in mind. Remember that breaking the build causes even more grief for remote developers, because every change they subsequently have to pull to fix it has a heavier time cost. Besides, if they're on a different time zone, they might not discover your mistake until you're snoring in bed, so they have to wait until your next day, which is their next night.

4. Thou shalt defend the orphan. That includes you and anyone else working remotely. Development procedures often evolve without consideration for their impact on DCD. Someone decides that it would be a good idea to insure that a particular file is always up to date, so they add an unconditional version control "pull" to part of a build procedure. That doesn't present a problem for developers on the gigabit LAN, but it brings builds to a screeching halt when you're getting less than a megabit down (or not even connected to the repo host). Remote developers have to insist on opt-in-only access to the central repo — or at least a single opt-out to all automatic access.

5. That which is united shall not be put asunder. Separate concerns carefully between teams. Too many interdependencies will waste just as much time as a broken build when one team has to wait for another to complete a component or make a decision before they can move ahead. Oddly, finger-pointing also becomes more prevalent when the rightful target of the finger is not well established.

6. Small and frequent shall be thy deliverables. It's always a good idea to break projects down into smaller components, just to ease project management. But it's even more important for DCD, because the impact of a commit/merge on the main product becomes more manageable and predictable. In contrast, a huge and as yet unseen deliverable looms silently and ominously on the horizon.

7. Thou shalt not leave thy fellow developers in the dark. Communicate, communicate, communicate. You may think you know what you're supposed to deliver, but the other teams may have a vastly different expectation. You don't want to find that out when you're done. Remote developers may not be able to be present at daily meetings, so they have to use other ways of staying up to date, and keeping everyone else updated on what they're doing. Video conferencing still hasn't achieved wide acceptance, so regular emails and phone calls often fill the gap. A private wiki can be helpful, because it holds the entire topic of conversation together for posterity.

10. Thou shalt not use octal. It confuses people.

About

Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant b...

Editor's Picks

Free Newsletters, In your Inbox