Beyond Chaos: The Expert Edge in Managing Software Development (ACM Press) [Paperback]

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 pointless than a meeting where there is an underlying tension that is never released and people leave even madder and more frustrated than when they started.
The points made in this collection of papers will not easily turn your enterprise around, although each is a tweak of the rudder pointing you to the right course. There is no "magic spell" that you can read and apply to make everything work out. However, there are so many things that you can do to incrementally improve how you create software and several can be found in this book. The tips range from the cradle to the grave of a software project and they will work if you apply them with honesty and resolve.

I bought this book when I was promoted to team leader 6 months ago. This is a great collection of wisdom for the new manager, especially Chapter 7 - First Things First: A Project Manager's Primer. As this chapter says from the start, most people are promoted without much if any training. This is a good starting point. The close of the book - Chapter 45 - was also one of the highlights. This is Constantine's advice to new leaders and those who wish to become leaders. He makes a nice distinction between pure management, to which he claims to have nothing new to add, and leading software development.

The book is broken down into 6 areas (It's About People, Project Management, Under Pressue, Quality Required, Processes and Practices, and Leadership and Teamwork) each containing about 8 chapters. You may think that is a lot of ground to cover in a book, and it is. The chapters in Quality Required didn't seem to be as relavent to their area as the others did. Quality means a lot of different things to a lot of different people so this is difficult no doubt. I found the firt two and last two areas of the book to be the most helpful.

This may seem contradictory to the above paragraph, but I felt the book was too long. Compared to other books such as "The Manager Pool" and "Facts and Fallacies of Software Engineering", this book is hard to finish in short bursts. Five pages was about tops for a chapter in the other books while it was typically the minimum for this book. That doesn't make Beyond Chaos a bad book. As I've said it has great information. Just don't expect to breeze through the information.

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 Maguire
VP Product Development
Vantage