Rating: 
Summary: Useful bag of tricks, if a little basic
Review: This book reads very well, and I truly enjoyed the afternoon spent perusing it. I would summarize it as presentation of a useful bag of tricks accumulated by the author, targeted at second year comp sci students. Be aware, though, that the author has not worked on large scale or complex problems, and his bag of tricks will need to be upgraded to more formal and robust approaches, common in the industry, as you try to tackle more difficult problems. For example, his 'write user manual first, then spec, then help file, then code' will need to be replaced by one of the formal sw development methodologies, his RFA will be replaced with one of the formal risk analyis techinques, his 'autolog debugging messages' will likely become a tracing tool allowing remote debugging and dynamic tracing levels, etc.
I was surprised to find out that the author did not focus more on testing and writing test cases, (after all, how else do you debug your code if not by running unit and system tests?), and code walkthroughs (after all, this would be the usual way of getting another pair of eyes, as he suggests), logging and tracing strategies (interactive debuggers are great, but they can not be shipped with the with the product and can not be turned on remotely to generate a log), etc.
If you are intested in improving your personal software development process, you may find books on PSP (Personal Software Process) interesting.
Overall, though, I found the author presenting a coherent point of view and I definitely found it worth the monetary outlay :-)
Rating: 
Summary: I'm buying a copy for each of my engineers
Review: This is a great book. It is inusual in that it talks about techniques and methodologies rather than just reiterating a bunch of APIs. It discusses how to avoid bugs in the first place, and how to code defensively, and how to present abnormal conditions to users. It talks about how to cope with the inevitable deadlines, and how to design programs (like write the user manual FIRST, instead of last).Every so often a book comes along that you know instantly must be read by all your colleagues. This is one of those books. I'm ordering a copy for each of my staff today, and we're going to decide which of the author's recommendations to adopt (maybe all of them). Only about half of this book is really about "Debugging Java". The rest of the book could be titled "How to Develop Quality Software" and could be used with other languages (although if you care about quality software you're already programming in Java anyhow). Buy this book. As soon as you get your hands on it make sure you write your name in it, because it'll get passed around a lot!
|
