Subscribe via RSS Feed

Latest column up: problems with distributed development

July 7, 2008 3 Comments

Sorry I haven’t posted much lately; I actually have a few posts in draft status, but I’m currently in Dallas, pouring over hundreds of pages of source code listings (Z8 assembler, anyone?) and haven’t had a chance to finish up any of them. In the meantime, here’s my latest Baseline column on the challenges of a (geographically) distributed software development project. Part II will be on techniques to help make such an effort successful; feedback is always welcome.

[Response to comments — WordPress for some reason won’t recognize that I’m signed in and let me post directly in comments myself]

Yurri writes:

It’s true that managing a distributed team is much more challenge than having all your crew at the one office. It’s definitely true but obvious also.

To you and me, perhaps, but not to to many organizations, large and small. Such organizations still operate — consciously or not — on the assumption that IT engineers are interchangable components, which includes a naive belief that it really doesn’t matter where all the IT engineers are located as long as you have enough of them. If you don’t believe me, consider how many organizations still consider it perfectly feasible to have a joint offshore/domestic software project.

The only thing that i can’t agree in this article is that oil prices play main role in distributed software development expansion. Tickets cost still remain minor part of relocation expenses as I can expect.

I must not have been clear enough. The sharp rise in gas prices encourages telecommuting — have IT engineers work from home, rather than driving into work each day. The rise in airline ticket prices also discourages having distant engineers fly for meetings as often as they should. I actually fully agree that the rise in airline ticket prices is relatively minor compared to (a) hotel and meals costs, and (b) the benefits of having all the engineers getting together — but I also know that many corporations often use minor expenses as a reason to deny something. Think about it: how many organizations refuse to buy their IT engineers up-to-date development systems and tools, despite the fact that the costs of such computers and tools is a tiny fraction of the engineers’ salaries and the lost-opportunity cost of having IT projects delayed?

John writes:

[key factors include team size, talent of the engineers, team cohesion — go read his comment below]

I agree with all your observations. I’ve had distributed development work, and I’ve also had it cause real problems — and those factors pretty much were the difference. And, yes, I’ll be writing about that in the next column. ..bruce..

About the Author:

Webster is Principal and Founder at at Bruce F. Webster & Associates, as well as an Adjunct Professor for the BYU Computer Science Department. He works with organizations to help them with troubled or failed information technology (IT) projects. He has also worked in several dozen legal cases as a consultant and as a testifying expert, both in the United States and Japan. He can be reached at 303.502.4141 or at bwebster@bfwa.com.

Comments (3)

Trackback URL | Comments RSS Feed

Sites That Link to this Post

  1. Distributed Development (Part II) : Bruce F. Webster | July 19, 2013
  1. yurri says:

    There is nothing to write a comment about in this article. It’s true that managing a distributed team is much more challenge than having all your crew at the one office. It’s definitely true but obvious also.

    The following parts must be more interesting telling about solving problems – and this first part only declares that the problem exists.

    Yes, it does.

    The only thing that i can’t agree in this article is that oil prices play main role in distributed software development expansion. Tickets cost still remain minor part of relocation expenses as i can expect.

  2. arandomJohn says:

    Bruce,

    You might be getting to this in the next column, but here are a few thoughts. Number one is that the size of the project matters. Something that requires 40 people working on it is simply not going to be able to be massively distributed in the way that something that has 5 people on it might.

    Second, the talent required matters. Many people think that it makes a lot more sense to have A+ developers all working at home than to have B developers all working in an office. Often people with the set of skills you need aren’t willing/able to relocate. If they are capable of being productive while working at home then you need to decide if you need those skills on your team.

    Finally there are the problems of team cohesion and interaction. The idea of the virtual company, with workers flung across the continent or even the globe is one that is gaining traction. On key is to spend some the the $$$ that are saved on office space on getting together in real life at regular intervals. For example, a team of 6 might meet together in a different location one week each quarter. This would be expected to be an intense, 80 hour week in which everybody gets to work on everybody else’s code and everybody gets on the same page. The core problem is being willing to spend the money to do this. Four weeks of travel a year isn’t much of a burden in exchange for working from home, assuming that you can work from home.

    I’ve been working from home consistently for 5 years now and I’ve seen it work well and be a disaster. Personally I think that the key is getting a small A+ team than can be productive at home and having the discipline to do the face to face meetings regularly and being able to realize when it isn’t working. I look forward to seeing your thoughts on what it takes to make distributed development work.

Leave a Reply

You must be logged in to post a comment.