Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Debugging: Indispensable rules for finding even the most elusive problems (2004)

dwheeler.com

Post reply on HN
Print view View original

91–100 of 238 posts

Re: Debugging: Indispensable rules for finding even the most elusive problems (2004)

#91

Post by seanwilson »

Ragnarork wrote: post #49
seanwilson wrote: post #43

Earlier quoted context omitted.

I don't think this is always worth it. Some tests can be time consuming or complex to write, have to be maintained, and we accept that a test suite won't be testing all edge cases anyway. A bug that made it to production can mean that particular bug might happen again, but it could be a silly mistake and no more likely to happen again than 100s of other potential silly mistakes. It depends, and writing tests isn't fr…

Writing tests isn't free but writing non-regression tests for bugs that were actually fixed is one of the best test cases to consider writing right away, before the bug is fixed. You'll be reproducing the bug anyway (so already consider how to reproduce). You'll also have the most information about it to make sure the test is well written anyway, after building a mental model around the bug. Writing tests isn't free,…

> Writing tests isn't free, I agree, but in this case a good chunk of the cost of writing them will have already been paid in a way.

Some examples that come to mind are bugs to do with UI interactions, visuals/styling, external online APIs/services, gaming/simulation stuff, and asynchronous/thread code, where it can be a substantial effort to write tests for, vs fixing the bug that might just be a typo. This is really different compared to if you're testing some pure functions that only need a few inputs.

It depends on what domain you're working in, but I find people very rarely mention how much work certain kinds of test can be to write, especially if there aren't similar tests written already and you have to do a ton of setup like mocking, factories, and UI automation.

Re: Debugging: Indispensable rules for finding even the most elusive problems (2004)

#92

Post by burrish »

omkar-foss wrote: post #81

For folks who love to read books, here's an excerpt from the Debugging book's accompanying website ( https://debuggingrules.com/ ): "Dave was asked as the author of Debugging to create a list of 5 books he would recommend to fans, and came up with this. https://shepherd.com/best-books/to-give-engineers-new-perspe... "

thanks for the link

Re: Debugging: Indispensable rules for finding even the most elusive problems (2004)

#93

Post by forrestthewoods »

jerf wrote: post #57
nickjj wrote: post #33

For #4 (divide and conquer), I've found `git bisect` helps a lot. If you have a known good commit and one of dozens or hundreds of commits after that is bad, this can help you identify the bad commit / code in a few steps. Here's a walk through on using it: https://nickjanetakis.com/blog/using-git-bisect-to-help-find... I jumped into a pretty big unknown code base in a live consulting call and we found the problem pr…

"git bisect" is why I maintain the discipline that all commits to the "real" branch, however you define that term, should all individually build and pass all (known-at-the-time) tests and generally be deployable in the sense that they would "work" to the best of your knowledge, even if you do not actually want to deploy that literal release. I use this as my #1 principle, above "I should be able to see every keystrok…

> why I maintain the discipline that all commits to the "real" branch, however you define that term, should all individually build and pass all (known-at-the-time) tests and generally be deployable in the sense that they would "work" to the best of your knowledge, even if you do not actually want to deploy that literal release

You’re spot on.

However it’s clearly a missing feature that Git/Mercurial can’t tag diffs as “passes” or “bisectsble”.

This is especially annoying when you want to merge a stack of commits and the top passes all tests but the middle does not. It’s a monumental and valueless waste of time to fix the middle of the stack. But it’s required if you want to maintain bisectability.

It’s very annoying and wasteful. :(

Re: Debugging: Indispensable rules for finding even the most elusive problems (2004)

#94

Post by bcantrill »

jgrahamc wrote: post #86

Wasn't Bryan Cantrill writing a book about debugging? I'd love to read that.

I was! (Along with co-author Dave Pacheco.) And I still have the dream that we'll finish it one day: we had written probably a third of it, but then life intervened in various dimensions. And indeed, as part of our preparation to write our book (which we titled The Joy of Debugging), we read Wheeler's Debugging. On the one hand, I think it's great to have anything written about debugging, as it's a subject that has not been treated with the weight that it deserves. But on the other, the "methodology" here is really more of a collection of aphorisms; if folks find it helpful, great -- but I came away from Debugging thinking that the canonical book on debugging has yet to be written.

Fortunately, my efforts with Dave weren't for naught: as part of testing our own ideas on the subject, I gave a series of presentations from ~2015 to ~2017 that described our thinking. A talk that pulls many of these together is my GOTO Chicago talk in 2017, on debugging production systems.[0] That talk doesn't incorporate all of our thinking, but I think it gets to a lot of it -- and I do think it stands at a bit of contrast to Wheeler's work.

[0] https://www.youtube.com/watch?v=30jNsCVLpAE

Re: Debugging: Indispensable rules for finding even the most elusive problems (2004)

#95

Post by ahci8e »

GuB-42 wrote: post #48

Rule 0: Don't panic Really, that's important. You need to think clearly, deadlines and angry customers are a distraction. That's also when having a good manager who can trust you is important, his job is to shield you from all that so that you can devote all of your attention to solving the problem.

Uff, yeah. I used to work with a guy who would immediately turn the panic up to 11 at the first thought of a bug in prod. We would end up with worse architecture after his "fix" or he would end up breaking something else.

Re: Debugging: Indispensable rules for finding even the most elusive problems (2004)

#97

Post by ianmcgowan »

I used to manage a team that supported an online banking platform and gave a copy of this book to each new team member. If nothing else, it helped create a shared vocabulary.

It's useful to get the poster and make sure everyone knows the rules.

https://debuggingrules.com/download-the-poster/

Re: Debugging: Indispensable rules for finding even the most elusive problems (2004)

#99

Post by nottorp »

ajross wrote: post #83
nickjj wrote: post #33

For #4 (divide and conquer), I've found `git bisect` helps a lot. If you have a known good commit and one of dozens or hundreds of commits after that is bad, this can help you identify the bad commit / code in a few steps. Here's a walk through on using it: https://nickjanetakis.com/blog/using-git-bisect-to-help-find... I jumped into a pretty big unknown code base in a live consulting call and we found the problem pr…

Not to complain about bisect, which is great. But IMHO it's really important to distinguish the philosophy and mindspace aspect to this book (the "rules") from the practical advice ("tools"). Someone who thinks about a problem via "which tool do I want" (c.f. "git bisect helps a lot"[1]) is going to be at a huge disadvantage to someone else coming at the same decisions via "didn't this used to work?"[2] The world is…

Just be careful to not contradict #3 “Quit thinking and look”.

Re: Debugging: Indispensable rules for finding even the most elusive problems (2004)

#100

Post by nottorp »

waynecochran wrote: post #15

I also think it is worthwhile stepping thru working code with a debugger. The actual control flow reveals what is actually happening and will tell you how to improve the code. It is also a great way to demystify how other's code runs.

This is necessary sometimes when you’re simply working on an existing code base.
Post reply on HN