The authors wrote better than they knew. My own experience is that reverse engineering is at least 20% of a typical software engineer's typical day. It's the study that a developer puts towards understanding a system well enough to make necessary changes, rediscovering enough about the system to enable the task at hand. The authors addressed their book to specific re-engineering projects, as isolated events, but they really wrote about the everyday life of almost every programmer.

As Johnson points out in the foreword, much if the information has an "everybody knows that" feel about it. I found a few new tips or new phrases, but mostly I found a clear, systematic organization of facts and techniques that are widely applied. The authors' arrangement of known techniques makes them especially valuable, much the way an arrangement of ordinary playing cards can become a valuable hand in poker.

Among other things, these authors are the first to convince me that software metrics can be a net gain to a developer. My own, sad exposure to metrics has been normative, a stick wielded blindly in the name of misunderstood "quality". This book shows how to use metrics in a constructive, exploratory way. The complexity (or whatever) scores are not the output of the process, they are intermediate results to be discarded as soon as they've pointed the way to the real problems.

I found only a very few points to disagree with. For example, the authors point out pros and cons of prototypes, but missed the biggest danger of a working prototype: that, no matter what caveats are given, it can be mistaken for a real system. Over-eager clients or managers driven by a false sense of efficiency may demand that the developers just add a feature or two (usually, system's entire capability) and ship it tomorrow. Elsewhere, the authors noted that converting from a command line interface to a GUI can be jarring for users, but did not point out that a GUI can provide a command entry field, at least as a transition aid. I would also have been happier with a longer discussion in ch.10 of type checking - I agree with the authors completely, but feel that they missed some common variations on the type-testing theme and reasons for it.

The authors suggested using dot plots for describing similarity between bodies of code, a representation I first saw in genome analysis. It strengthens the image of a program as a living, evolving thing, but also suggests that other genomic tools could possibly have value in understanding software. Programs are really just long strings, and geneticists have a huge box of subtle tools for analyzing long strings. Mating of the two fields could spawn a new generation of techniques for extracting information from existing software.

I recommend this book very highly. It's thorough, practical, and readable. It addresses software maintenance - i.e., most of the software industry - as a valuable task, worth serious study and investment in tools. A brief review can't do justice to the book's rich content. I hope you explore it for yourself.