A must have book for anyone writing programs.
— www.felgall.com
Overall, this book is going to be a huge win, and I think it’s a worthy successor to the Release It! reputation. Development managers and team leads should get a copy for the junior developers on their team as a Christmas gift, but only after the senior developers have read through it as well.
— blogs.tedneward.com
Excellent discussion of the strategy of debugging. Buy, it read it and kill bugs.
— i-programmer.info
Frankly, I wish this book would be read by a lot of developers
— www.jasonbock.net
With my many years of experience in supporting and debugging large existing enterprise systems, I have to say that Paul Butcher summarize and structure all the knowledge (and more) that I have, sometimes painfully, accumulated during this activity. This is therefore an excellent book that I will recommend to everybody that is involved in software development in general and maintenance activities specifically.
— blog.martinig.ch
I know that this book influenced the way I work now, and there aren’t many books I could say something like this about.
— devlicio.us
All in all, there is just a lot of tremendously valuable information in this book. And it’s only about 190 pages so it definitely won’t take you a long time to read it. I’ve frequently been amazed at the inability of developers to efficiently debug issues when they occur. And i’m not just talking about bad developers. I’ve seen plenty of good or even great developers having trouble with debugging efficiently. This book would definitely get them on the right track, with just a little bit effort.
— davybrion.com/blog
Understanding is everything: that is at the heart of Paul Butcher’s comprehensive study of the science and psychology of debugging.
— softtalkblog.wordpress.com
The book does a great (and truly pragmatic) job of covering all these aspects and addressing a wide range of topics related to debugging software.
— hamagudi.com
If you are too busy to read this delightful book in its entirety, then at least read the final chapter whilst mandating that your entire development team read “Debug It!” from cover to cover.
— javablog.co.uk
I would highly recommend Debug It! to any junior-level programmer who’s interested in developing a more disciplined approach to debugging. If you’re not a junior-level programmer but still feel like you waste a lot of time debugging, you will probably find this book helpful as well. It’s like having a mentor sitting there with you, teaching you how to take your debugging game to the next level.
— lylejohnson.name
It’s really good seeing these ideas in words because it’s quite easy to forget about the best way to approach problems in the heat of the moment and the approaches suggested by Paul certainly aren’t done everywhere in my experience.
— www.markhneedham.com
While I was familiar with many of the practices discussed in the book … I learned quite a few new things.
— starglider.blogspot.com
It does a great job of setting the scene for debugging and getting you into the right mind set, while also talking about the complications that can arise once the bug is found and squashed. It’s almost worth looking at for the anecdotes alone, to understand the lengths that you sometimes have to go to when trying to understand some truly bizarre defects.
— blog.jonmdickinson.com
This is a recommended read for anyone who works closely in the software industry, be it a developer, a tester or even a product manager.
— vidhujoshua.blogspot.com
Debug It! is making its way around the world, as this review by Luiz Marques in Brazil demonstrates.
Luiz is kind enough to say:
While I was familiar with many of the practices discussed in the book … I learned quite a few new things.
He goes on to say:
Well worth the time, specially as it is not very long.
Many thanks, Luiz.
You’re recovering from a major operation—which nursing unit do you choose? One that reports an error once every 500 patient days, or one that reports an error once every 50 days?
What if I were to tell you that in the first unit, which on the face of things makes 10 times fewer mistakes, nurses don’t report errors because they’re concerned that “heads will roll.” Would that change how you feel? How many errors are being swept under the carpet? Do you think that they’re likely to be learning from their mistakes or repeating them over and over again? (This example comes from Hard Facts, Dangerous Half-Truths & Total Nonsense by Jeffrey Pfeffer and Robert I. Sutton, Harvard Business School Press, ISBN: 1-59139-862-2.)
In software, we have our own name for mistakes—we call them bugs. And every bug is an opportunity to learn.
To read the rest of this article, take a look at Issue 6 of PragPub magazine
Sample source for section 10.3 “Resource Leaks and Exception Handling” is online here.
It’s setup to run in Visual C++ 2008, but should be relatively easy to port to other environments.
Any questions, you know where I am!
Ted Neward has just published a review of Debug It! on his blog.
His summary is:
Overall, this book is going to be a huge win, and I think it’s a worthy successor to the Release It! reputation. Development managers and team leads should get a copy for the junior developers on their team as a Christmas gift, but only after the senior developers have read through it as well. (Senior devs, don’t despair—at 190 pages, you can rip through this in a single night, and I can almost guarantee that you’ll learn a few ideas you can put into practice the next morning to boot.)
Krzysztof Koźmic has just published a review of Debug It! on devlicio.us:
http://devlicio.us/blogs/krzysztof_kozmic/archive/2009/08/30/book-review-debug-it-find-repair-and-prevent-bugs-in-your-code.aspx
Within the review, he says:
I know that this book influenced the way I work now, and there aren’t many books I could say something like this about.
Which is the best compliment I can imagine as an author. Very many thanks, Krzysztof.
The first couple of reviews of Debug It! have recently been published:
Book Review: Debug It!
Debug it! A Book on Software Debugging
The Pragmatic Programmers have just started publishing an online magazine: PragPub. Among other things, it contains a quiz which in this issue tests your knowledge of programming languages.
I consider myself a bit of a languages geek, so I thought that I’d have no trouble with it. But it’s driving me mad!
The quiz consists of little snippets of code in different languages. The first letters of each language then spell out the name of another language.
I can get 5 of the 6, but one of them has me completely stumped. Even though I’m 99% sure what letter it’s name must start with.
Warning: Spoilers follow!
Continue reading ‘Help, this is driving me mad!’
As you may know, I’ve been working on a book. It’s been a long process, but the finishing line is finally in sight – as of today, it’s available as a “Beta Book” from The Pragmatic Bookshelf:
http://pragprog.com/titles/pbdp/debug-it
This means that it’s available for purchase and download as a PDF and ebook, and the paper version can be pre-ordered. 
This article originally appeared upon on texperts.com
So the new 3G iPhone is here (for those of us lucky enough to win the O2 website lottery or patient enough to queue up on Friday morning, at least).
Although I’ve not yet had a chance to play with the 3G version, I’ve been very impressed with the version 2.0 software (apart from an annoying pause it seems to have introduced whenever I view my contacts).
But I am amazed! at the shambles that the launch has become.
One of the key insights of modern agile development methodologies (like Scrum, Extreme Programming and Crystal Clear) is that “big bang” releases are never a good idea. Instead, they use iterative, incremental releases. What Apple tried with the iPhone launch was the biggest of big bangs imaginable!
In one day, they tried to:
- Release a new version of a handset globally
- Release a new version of the desktop (Mac or PC) software which interfaces with that handset
- Release a new version of the software running on existing handsets
- Release a new version of the back-end server technology (MobileMe) supporting all the above
The upshot of all of this? Nobody could upgrade their handsets when O2’s systems collapsed under the load. Then people’s iPhones became bricks when upgrading to version 2.0. Then MobileMe was down for maintenance for much longer than intended and is still only limping along.
Anyone who has ever been involved in large software/IT projects could have worked out that this was guaranteed to happen. Big bangs don’t work. Why was Apple unable to forsee this?
The iPhone is a lovely device. But Apple have badly tarnished their reputation in my eyes.
