Liz and Rachel,
Firstly, congrats on a well done book! There are lots of great tips for coaching agile teams that many people will put to good use.
There was one small tidbit I strongly disagreed with. Liz made a note on page 158 entitled “No Comments” stating that the team should be encouraged to avoid writing comments because they clutter the code and cannot be relied upon to be accurate. Good code is supposedly clear and obvious without comments. I disagree wholeheartedly.
Inaccurate comments are mostly due to laziness and lack of attention to detail, which also leads to bugs. Additionally, even with a well named variable or function, the INTENTION of the code may not be obvious. Good comments address the “WHY” of the source code, which is not obvious in any other way. It is true that comment blocks may be a sign that refactoring (e.g. extract method) is needed, but that should not preclude intention comments. I blog a bit about this at http://blogs.msdn.com/progressive_development/archive/2007/08/28/motley-says-code-comments-are-for-sissies.aspx (note that the title of the blog is intentionally the opposite of the message).
In strongly encourage you to revamp this piece of “advice” for future editions as it could lead a junior developer astray. Comments are a necessity, particularly when you can keep your low-level design documentation in the code and generate docs in a nice format afterward (e.g. C# XML comments).