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.
