As a software development consultant, I've been one of those dispersed team members for most of the last 16 years. Back in 1991, I started telecommuting to my clients' systems via 9600 baud modem (that's 9.6 kpbs, for those of you too young to know what "baud" means -- it wasn't as bad as it sounds, because everything was character-based back then). The rise of the web and global email have made working remotely a lot more effective, but "being there" only virtually still presents its challenges.
About ten years ago, I took on a project with a company on the opposite coast. They had already managed to port their application from character-based platforms to Windows, but the user interface needed serious graphical help. Since this was a pretty standard migration in my segment of the industry, I was quickly able to outline quite a few steps that they would need to take to get to where they could release a Windows product that wouldn't be laughed out of the sales demo. In a large application that has evolved over decades, changes to the user interface cannot usually be effected in just one or even a few places. While the modifications were relatively simple, the effort required would be far from trivial.
As often happens, the client replied that they just didn't have the resources to implement my recommendations, and asked if I knew anyone or if I would be willing to do it for them myself. I ended up subcontracting two programmers that I knew and trusted, and within a few months we had updated the whole UI.
In the meantime, though, the customer continued to enhance their application (a different copy than what we were working on -- this was before VPNs were available), so when I presented our update they asked me to apply the same changes to their newer version. Thankfully, my team had used version-control software (PVCS) to track their modifcations, but the number of enhancements the other team had implemented forced us to revisit much of what we had done the first time around. Nevertheless, after a few weeks we had the new version back to them.
Well guess what. Within that time they had implemented even more enhancements. Back and forth we went, swapping copies of the entire application's source code on CD via FedEx, trying to get to a unified version. Then we learned that the other team didn't want to adopt our modifications, because they didn't have time to learn what we had done so they could work with our code (proper separation of UI from business logic would have been a much larger task that wasn't even on the radar). Our UI modifications ended up on the shelf, and several years would pass before the company was finally under enough market pressure to force them into seriously updating their user interface.
The wasted time and expense left a bad taste in everyone's mouth, and I never did any more work for that client. But I did learn a few important lessons about working remotely, some of which coincide with the bullets in Tom's post:
- Share fairly. Everyone who touches source code needs to use a common set of archives. Nowadays you can pretty easily set up a VPN or a web-based collaboration site to provide protected, global access to source code. But if (for whatever reason) that isn't practical, then everyone needs to know who has control over what portions of the source at any given time. Even if that creates delays while waiting for an unlock, it will save the time you don't spend trying to merge modifications to the same files later.
- People are more important than processes. If some team members resent part of what you're trying to accomplish, they'll find ways to torpedo it. This can even happen without malice, through neglect, if they don't have a clear understanding of the benefits of your contributions. Communication between teams is more important than any number of source code comments.
- Make sure you know the whole story. Beyond the specific tasks you're given to work on, learn as much as you can about all the factors that might be pushing the project around. In our case, we had been told that the Windows upgrade was the number one priority for the company, when it turned out that they were under even more pressure to add businesss logic enhancements instead.
Better yet, if you can successfully identify a corporate culture that disables any of the above, don't take the engagement!
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 blog, he also contributes to [Geeks Are Sexy] Technology News and his two personal blogs, Chip's Quips and Chip's Tips for Developers.