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]
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?
[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: bfwebsterWebster 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 email@example.com.
Sites That Link to this Post
- Distributed Development (Part II) : Bruce F. Webster | July 19, 2013