Output Stream of Consciousness

Link: http://www.amazon.ca/gp/product/0932633439?ie=UTF8&tag=thecerealkill-20&linkCode=as2&camp=15121&creative=330641&creativeASIN=0932633439

This is an interesting paperback concerning itself with how companies are run where the business is development, like code, as opposed to production, like cheeseburgers. In particular, there is a focus on what sort of management mismatches and business pathologies you may encounter.

If you are a developer, chances are that you will identify with some-to-many of the troubles in this book...

Environment is key. Development requires ramp-up time to get into any particular activity. Noise, phones, interruptions can take a significant toll. Noise, in particular, can take away insight, according to one of the studies they quote. Productivity was seriously affected by noise and number of people co-inhabiting the space but so, too, was defect rate.

Productivity is affected by other factors as well. Some time is spent debunking Parkinson's Law, in which work expands to fill the time available. This is used to pre-judge workers as intrinsically lazy, and to justify practices such as overtime, artificially shortened timelines, and depersonalization. Parkinson's Law is false for most developers. Read the section on productivity versus estimates, and have your eyebrows raised in intrigue.

They make much ado about turnover. Turnover can affect how your company does its tasks. Training and skills investment is unlikely in a high turnover situation. As well, with knowledge work, new hires are almost by definition non-productive or even counter-productive. Replacing someone costs, by their estimation, about six man-months' worth of salary.

Teambuilding, and trying to keep team cohesion, get good treatment in the book. Practices like breaking up teams after every project, and discouraging trust in a team (including, in particular, extended overtime situations, where single people with no kids will come involuntarily to despite team members with family who "can't stay"). One interesting section talks a lot about a part of the company which could really use cohesion and a team effort: middle management, in particular because organizational learning happens at the middle management level, if it happens at all.

The "furniture police" get a knuckle-rapping, with the drive towards cubicles and other forms of endless repetition. So, too, does praying to Methodologies-with-a-capital-M. For example, striving for CMM status often kills necessary risky/blue sky projects.

There's more to the book. It's full of good ideas and observations, though some of the metaphors are odd (Open Kimono, for example, even though it's industry vernacular, is disturbingly presented), and some of the ideas highly idealistic even if good at their heart (like allowing office spaces to evolve organically, or having team-building sessions off-site and overnight).

I suppose the worst thing I could direct at this book is that the content feels more amateurly-written than it should be if the idea is ever to give the book to those sorts of folks who need it most. The sections could use a lot of cleanup, reorganization, and presentation from a less subjective-sounding viewpoint. Better metaphors are required in some cases, more studies, if possible, and some awkward paragraphs ought to be simply dropped. The updates from the 1987 edition should be integrated instead of kept as add-ons, with an appropriate afterword/appendix.

(In other news, these issues that are still problems are things we knew about in 1987.)

That all said, the content is indeed good and much more often than not, spot on. De facto luminaries like Ed Yourdon and Scott Ambler, as well as populists like Joel Spolsky of Joel On Software fame have their review stamp of approval on the back.

The book seems a little pricy for its format, but it's relatively meaty on content. Buy it for yourself or a beloved geek. If you're an eternal optimist, buy it for your boss :)