It’s been a quiet spring from me, at least as for this medium. Busy and overwhelming year, this one. I’ve had some time to read, however, and I thought I’d post something on the two latest titles.
First out is Extreme Programming Installed, which takes a practical look at Extreme Programming. I’ve been looking for a book like this ever since I read its older sibling Extreme Programming Explained, the original work on XP.
Jeffries, Anderson and Hendrickson do a great job of explaining the practices in detail, supporting the reader and offering tips for how to make XP work. It’s much more fleshed out than what I’ve read so far, with good examples of planning, automated tests and steering. I sometimes think Ron Jeffries’ zen-style of writing can become tiresome, but I thoroughly appreciate his experience and his ability to share it.
Second, I finally took the time to read Fred Brooks’ classic: The Mythical Man-Month. It’s fascinating to learn of his experiences in 70’s OS development, and that the hurdles in project management are still mostly the same. I got my hands on an anniversary edition with four new chapters from 20 years later than the original texts — this was also really interesting to see Brooks look back on his earlier work.
I think what captured me the most was that so much of the ideas founded around managing software projects were so tightly bound by the technology. In fact, I would argue that’s still the case. Brooks comments in a section that the microcomputer revolution has antiquated many of his previous ideas, and I think that many truths around software project management then, as today, may be based on assumptions of context that may not necessarily hold forever.
As an example, Brooks at one point argued for a project workbook to be maintained, that is, a complete set of all relevant documentation for the project collected in a single set of binders. The idea was to increase the availability of information, so that every project member had the whole view at their hands at any one time. In order to make it easier to follow recent changes, a change log would be maintained. That way, you could pick up what was changed in the potentially massive body of work, and see if it had any effect on what you were currently doing.
In 1975, this was probably as good a way as there was to share information. 15-20 years later, an intranet or project web would be the modus operandi, and these days, agile proponents argue you should just Sit Together. I think it makes sense to always revise what you’re doing and why, and whether it still makes sense for the type of work you’re doing in the context you’re doing it and with the tools available.
Good books, both of them.