"The Deadline"

During my christmas vacation, I read "The Deadline", by Tom DeMarco. The book greatly exceeded my expectations. It's truly enjoyable to read, and there were at least a dozen times when I had to to put the book down and take a walk, to think about what was said.

The book is packed with opinions on how to be a good manager. The suggestions are useful even if you aren't a manager, because they can give you a different perspective on how you relate to your boss -- for example, if you're having trouble feeling motivated, or it feels like you waste all your time in meetings, is that your problem or is it a management failing?

DeMarco presents his ideas in the context of an ongoing story, which is delightfully simple and fairy-tale-like. The story format has the advantage of giving the reader a feeling for the context in which his opinions are meant to be applied. Too often, books like this can devolve into general principles that sound great but don't really convey a feel for how to use the ideas in practice.

One interesting idea in the book was to try to create a software model of your team. This involves assigning numbers to how many features you can do per day, what your employee turnover rate is, your training time, time spent in meetings, the complexity of the software that has to be written, and so on. This seems like the kind of idea that would work best with groups that are large enough to be treated statistically -- it's probably not meant for groups of only half a dozen developers. But it was interesting nonetheless, because I had never considered trying to quantify the management process to such a degree.

Another interesting idea was to chart progress in terms of feature tests that pass, rather than a nebulous judgement as to what percentage of the code is written (which tends to leave out debugging time entirely). I've seen this idea in several guises before (test-driven development is founded on it), but I was glad to see it mentioned again.

One of the more controversial ideas which the book suggests (but doesn't actually condone) is to try to get rid of debugging entirely, by putting off implementation until the very end of the project and making sure that the up-front design is as complete and thorough and reviewed as possible. It's an intriguing idea because it harkens back to the waterfall development model, and seems to run completely counter to the agile development model that has been so popular recently. Given that the book was written in 1997, I'd have expected him to provide more justification for this apparent throwback to methodologies that seem to have failed.

Chapter 1 of the book is available online. It should give you a feel for how enjoyable a read the book is.