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

61–70 of 238 posts

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

#61

Post by jerf »

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,…

For people who aren't getting the value of unit tests, this is my intro to the idea. You had to do some sort of testing on your code. At its core, the concept of unit testing is just, what if instead of throwing away that code, you kept it?

To the extent that other concerns get in the way of the concept, like the general difficulty of testing that GUIs do what they are supposed to do, I don't blame the concept of unit testing; I blame the techs that make the testing hard.

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

#62

Post by [deleted] »

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…

[deleted]

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

#63

Post by nickcw »

ChrisMarshallNY wrote: post #42

#7 Check the plug: Question your assumptions, start at the beginning, and test the tool. I have found that 90% of network problems, are bad cables. That's not an exaggeration. Most IT folks I know, throw out ethernet cables immediately. They don't bother testing them. They just toss 'em in the trash, and break a new one out of the package.

I prefer to cut the connectors off with savage vengeance before tossing the faulty cable ;-)

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

#64

Post by jerf »

soco wrote: post #21
david_draco wrote: post #13

Step 10, add the bug as a test to the CI to prevent regressions? Make sure the CI fails before the fix and works after the fix.

What do you do with the years old bug fixes? How fast can one run the CI after a long while of accumulating tests? Do they still make sense to be kept in the long run?

I'm not particularly passionate about arguing the exact details of "unit" versus "integration" testing, let alone breaking down the granularity beyond that as some do, but I am passionate that they need to be fast, and this is why. By that, I mean, it is a perfectly viable use of engineering time to make changes that deliberately make running the tests faster.

A lot of slow tests are slow because nobody has even tried to speed them up. They just wrote something that worked, probably literally years ago, that does something horrible like fully build a docker container and fully initialize a complicated database and fully do an install of the system and starts processes for everything and liberally uses "sleep"-based concurrency control and so on and so forth, which was fine when you were doing that 5 times but becomes a problem when you're trying to run it hundreds of times, and that's a problem, because we really ought to be running it hundreds of thousands or millions of times.

I would love to work on a project where we had so many well-optimized automated tests that despite their speed they were still a problem for building. I'm sure there's a few out there, but I doubt it's many.

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

#65

Post by adamc »

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.

I had a boss who used to say that her job was to be a crap umbrella, so that the engineers under her could focus on their actual jobs.

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

#66

Post by nthingtohide »

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.

Make sure through pure logic that you have correctly identified the Root Cause. Don't fix other probable causes. This is very important.

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

#67

Post by BlueUmarell »

Post: "9 rules of debugging"

Each comment: "..and this is my 10th rule: "

Total number of rules when reaching the end of the post: 9 + n + n * m, with n being number of users commenting, m being the number of users not posting but still mentally commenting on the other users' comments.

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

#70

Post by [deleted] »

BlueUmarell wrote: post #67

Post: "9 rules of debugging" Each comment: "..and this is my 10th rule: " Total number of rules when reaching the end of the post: 9 + n + n * m, with n being number of users commenting, m being the number of users not posting but still mentally commenting on the other users' comments.

[deleted]
Post reply on HN