Browse Books

Reviewer: Jon A. Meads

The first line of the first chapter, “Software development used to be the domain of engineers clad in white lab coats…,” is an indication that this book may be based more on the author's preconceptions than on fact. And, while the book is not all that good, it is not entirely bad either, and may be of value to some readers who do not have much management experience. However, readers will need to be able to discern where good advice is being offered and where out-of-date technology is being described or anecdotes cannot be generalized. For the most part, the author discusses global software teams at a high level and offers good advice and insight only at a high level. There is nothing here that you can put directly into practice, but the book includes things you would definitely want to be aware of if you were managing a global team, or any software development team. The book is divided into four parts. The first discusses the reasons why companies are forming global software teams. The reasons offered are to reduce development time, reduce costs by using less expensive programming expertise, obtain multicultural perspectives, and meet a global computing need. Though the last two are the only reasons really supported by the anecdotes and case studies, the author does not clearly acknowledge it. For example, there is an implication that “follow-the-sun” development, where programmers pass off code from one team to another for continued overnight programming, might actually work. The second part discusses centrifugal forces—the factors that can make global software teams less successful. For the most part, it turns out that those factors are the ones that can negatively affect all software teams working on large complex projects, but they can more severely affect global teams because of cultural differences and geographic distance. The third part looks at centripetal forces—the factors that can help make a global software team successful. Most of it is obvious (for example, the need for high-bandwidth communication), and I found nothing to disagree with. Chapter 10 might be most valuable to junior managers. It lists things to be aware of in managing global software teams. It is also good advice for managing any development team. The fourth part discusses different types of software teams. This part seems a bit pedantic. The author takes great care to identify and name different types of global software teams and the types of projects for which they are best suited. Again, it is all good high-level advice for organizing any software development effort, but it is most likely that teams will be developed ad hoc according to the specific needs of the project. Overall, the book is a bit long for the information provided and has an aura of not being connected with reality. One anecdote describes how a non-American developer's program did not provide feedback when an operation was successful—it just returned a prompt instead of indicating successful completion. Carmel sees this as an indication of a lack of multicultural awareness. However, this same sort of problem exists with much American-developed software. The need for feedback is a basic human factors issue, which is noncultural. In another case, the author notes that globally dispersed developers are limited in their communication to email, whereas co-located developers tend to ignore email in favor of face-to-face interaction. Either the data are old, going back to when email was much more difficult to use than it is today, or the author is just not aware of current software development practice, where even emailing someone in the same office is commonplace. In spite of these criticisms, the book could be useful, particularly in making readers aware of the organizational and management factors affecting software teams, global or not. However, it is not necessarily a book I would advise someone to purchase or read.