Beyond Chaos: The Expert Edge in Managing Software Development

by Larry L. Constantine

The popularity of the Management Forum in Software Development Magazine is not surprising. Because the majority of software development projects fail to come in on time, on budget, or on... This description may be from another edition of this product.

• Format: Paperback
• Language: English
• ISBN: 0201719606
• ISBN13: 9780201719604
• Release Date: January 2001
• Publisher: Addison-Wesley Professional
• Length: 416 Pages
• Weight: 1.15 lbs.
• Dimensions: 0.7" x 6.3" x 9.2"

Customer Reviews

Great thought-invokers

This book, consisting of short essays, had been sitting on my bookshelf for a long time. Finally, I picked it up when my summer vacation started and I actually felt sorry I hadn't done it earlier. Constantine and others present their thoughts about common problems in software development organizations and some methods to tackle these issues with. I keep nodding and sighing while reading the problem descriptions and keep on nodding as the authors proceed to how they have successfully solved the problems before. Good stuff!

Great for browsing or as a straight read

Having been in the software development business for many years, I have experienced most of the situations that are described in this instructive series of essays. The writers of the articles in the book and the editor, Larry Constantine, are all long time practitioners in the field and bring share deep experience level with entertaining case studies and solid advice. Although some of the ideas are somewhat idealistic (programmers forming an international software guild to enforce standards), others are practical and immediately useful. Even if, for you, some of the articles are "preaching to the choir", they may give you a different way to explain something you may already be doing, or help with additional justification for using an approach that many managers of the "ready, fire, aim" school of management don't see the need for. This not to say that this is one of those "heavy methodology" books; it isn't. It is disheartening when you see organizations make the same mistakes over and over. Readers of this book may be able to use some of the techniques described to keep their particular organization out of trouble. This book is an excellent and readable contribution to software development and software development management.

Well Done

I have read many of these types of books on simular topics and most of the time I wonder why I continue to keep getting them. I guess I keep hoping that the next book will be different. This book is different. It is very well written, edited, and organized. The chapters cover key areas and provide just enough information to take back to the "real world". Most of the project management and software management books force you to read 40 page chapters with 10-12 different bullets lists of 10 important points. This organization forces you to bounce around chapters or become overwelmed trying to take back 100 bulleted lists of important concepts. Beyond Chaos does not do this.Beyond Chaos has short chapters that have been beaten down to only include good brief case studies, key concepts and summaries. The contibutors speak from experience and have mastered the concepts not weeks or months ago, but years and decades ago.My only constructive critism is that a few of the chapters may not provide enough information or go indepth enough. They act more as excellent primers on the topic and could probably be books of their own.If you are looking for a book you will learn from and read cover to cover. Get this one.Excellent job Larry.Brian MaguireVP Product DevelopmentVantage

New solutions to development problems that are not new

There are several principles of software development that are well-known but not well applied. Pressing people to work long hours is one that has been shown over and over again to be counterproductive. Over the long term, regular overtime causes a decrease in productivity, leading workers to some rather innovative ways to compensate. For me and others, the management report meetings were an opportunity to catch up on our sleep. However, despite this overwhelming evidence, many organizations still cajole their workers to keep excruciating hours. It will probably never be known with certainty, but it seems a good bet that the long hours put in by dot-com workers contributed to many of the failures. When I first opened this book, I thought that it was just another of the many that I have seen recently explaining why so many software projects fail. While theses about things like the evils of mandatory overtime, the need for maintaining mutual respect among all levels, and providing appreciated compensation are all correct and important, those avenues have been thoroughly explored. So much so that I now find such descriptions generally repetitive and dull. Fortunately, I was pleasantly surprised when I read this book. While the collected papers do deal with such issues, the approach was refreshing. I thoroughly enjoyed the reference to the owner who was a joy to work for, his employees thought he was a great manager and he compensated them well. Right up to the day when he went bankrupt. The problem in the development world is not that it is rife with politics and conflict, that is a natural component of any environment containing humans. The real problem is learning how to accept their existence and channel it into avenues of increased production, which is the point of the solutions described in this collection of papers by several authors. My favorite was how to "control" office gossip. Of course you can't, but what you can control is how you react to it and what you say. Like the old game of telephone, nothing kills gossip quicker than someone who refuses to play. Setting down simple rules about saying what is and is not an acceptable point for discussion can do a great deal to reduce tensions. Other topics include the "demise" of the cow(boy and girl) coder, how to argue with your boss, how to accept arguments from your subordinates, how to productively argue with your hierarchical equals, how to accept and learn from failure; how to set deadlines, and how to be tough enough to succeed without turning into an example of the ugly manager. Some conflict in the work place is good, as there will never be a one correct way to build software. At times, even a bit of yelling can be refreshing to all concerned, provided it does not cross that fine line to the personal. Some of the most productive sessions I have attended started out with a great deal of yelling that immediately eliminated the tension so people could compromise. Nothing is more poin