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

221–230 of 238 posts

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

#221

Post by fud101 »

deepspace wrote: post #179
sitkack wrote: post #152

If folks want to instill this mindset in their kids, themselves or others I would recommend at least The Martian by Andy Weir https://en.wikipedia.org/wiki/The_Martian_(Weir_novel) https://en.wikipedia.org/wiki/Zen_and_the_Art_of_Motorcycle_... https://en.wikipedia.org/wiki/The_Three-Body_Problem_(novel) To Engineer Is Human - The Role of Failure in Successful Design By Henry Petroski https://pressbooks.bccampus.ca/e…

Agree. I think Zen and the Art of Motorcycle Maintenance encapsulates the art of troubleshooting the best. Especially the concept of "gumption traps", "What you have to do, if you get caught in this gumption trap of value rigidity, is slow down...you're going to have to slow down anyway whether you want to or not...but slow down deliberately and go over ground that you've been over before to see if the things you tho…

i'm slogging through zen, it's a bit trite so far (opening pages). im struggling to continue. when will it stop talking about the climate and blackbirds and start saying something interesting?

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

#222

Post by PaulHoule »

hughdbrown wrote: post #192
randerson wrote: post #182

Earlier quoted context omitted.

The quickest solution, assuming learning from the problem isn't the priority, might be to replace the entire chain of lights without testing any of them. I've been part of some elusive production issues where eventually 1-2 team members attempted a rewrite of the offending routine while everyone else debugged it, and the rewrite "won" and shipped to production before we found the bug. Heresy I know. In at least one c…

> The quickest solution, assuming learning from the problem isn't the priority, might be to replace the entire chain of lights without testing any of them. So as a metaphor for software debugging, this is "throw away the code, buy a working solution from somewhere else." It may be a way to run a business, but it does not explain how to debug software.

The worst cases in debugging are the ones where the mental model behind the code is wrong and, in those cases, "throw it away" is the way out.

Those cases are highly seductive because the code seems to work 98% and you'd think it is another 2% to get it working but you never get to the end of the 2%, it is like pushing a bubble around under a rug. (Many of today's LLM enthusiasts will, after they "pay their dues", will wind up sounding like me)

This is documented in https://www.amazon.com/Friends-High-Places-W-Livingston/dp/0... and takes its worst form when you've got an improperly designed database that has been in production for some time and cannot be 100% correctly migrated to a correct database structure.

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

#223

Post by PaulHoule »

tetha wrote: post #118
throwawayfks wrote: post #110

Earlier quoted context omitted.

I read this book and took this advice to heart. I don't have a brass bar in the office, but when I'm about to push a button that could cause destructive changes, especially in prod, my hands reflexively fly up into the air while I double-check everything.

A weird, yet effective recommendation from someone at my last job: If it's a destructive or dangerous action in prod, touch both your elbows first. This forces ou to take the hands away from the keyboard, stop any possible auto-pilot and look what you're doing.

Reminds me of https://en.wikipedia.org/wiki/Pointing_and_calling

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

#224

Post by feoren »

earnestinger wrote: post #184
feoren wrote: post #175

Earlier quoted context omitted.

Essentially yes, that's correct. Your mistake is thinking that the outcome of those months of work is being able to kinda-probably fix one single bug. No: the point of all that effort is to truly fix all the bugs of that kind (or as close to "all" as is feasible), and to stop writing them in the first place. The alternative is paradropping into an unknown system with a weird bug, messing randomly with things you don'…

> if the manual of a library you're using is 700 pages, you're probably using the wrong library. Statement bordering on papyrophobia. (Seems that is a real phobia)

More like fear of needless complexity and over-broad scope, which is actually rampant in library design.

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

#225

Post by n144q »

seanwilson wrote: post #185
n144q wrote: post #181

Earlier quoted context omitted.

I have, and in 90% of cases that's because my code is seriously messed up, so that (1) it is not easy to write a unit test (2) there has not been enough effort in testing so that mocks are not available when I need it. Adding tests is not easy, and you can always find excuses to not do that and instead "promise" to do it later, which almost never happens. I have seen enough to know this. Which is why I myself have pu…

I'm assuming here the code is written in a testable way, but the behaviour is hard or time-consuming to test. It's not about being lazy or making excuses, it's not free to write exhaustive tests and the resources have to come from somewhere. For MVPs, getting the first release out is going to be much more important for example.

You are not supposed to spend a significant amount of time testing "behavior". Unit tests should be the vast majority of testing.

And I can tell you I have first hand experience of an "MVP" product getting delayed, multiple times, because management realizes that nobody wants to purchase our product when they discover how buggy and unusable it is.

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

#226

Post by deepspace »

fud101 wrote: post #221
deepspace wrote: post #179

Earlier quoted context omitted.

Agree. I think Zen and the Art of Motorcycle Maintenance encapsulates the art of troubleshooting the best. Especially the concept of "gumption traps", "What you have to do, if you get caught in this gumption trap of value rigidity, is slow down...you're going to have to slow down anyway whether you want to or not...but slow down deliberately and go over ground that you've been over before to see if the things you tho…

i'm slogging through zen, it's a bit trite so far (opening pages). im struggling to continue. when will it stop talking about the climate and blackbirds and start saying something interesting?

Yes it starts slow, but keep at it. It starts to get interesting about halfway into the book, if I remember correctly.

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

#228

Post by seanwilson »

n144q wrote: post #225
seanwilson wrote: post #185

Earlier quoted context omitted.

I'm assuming here the code is written in a testable way, but the behaviour is hard or time-consuming to test. It's not about being lazy or making excuses, it's not free to write exhaustive tests and the resources have to come from somewhere. For MVPs, getting the first release out is going to be much more important for example.

You are not supposed to spend a significant amount of time testing "behavior". Unit tests should be the vast majority of testing. And I can tell you I have first hand experience of an "MVP" product getting delayed, multiple times, because management realizes that nobody wants to purchase our product when they discover how buggy and unusable it is.

We probably work on different kinds of projects and/or different kinds of teams? I'd rather have the majority being end-to-end/UI tests than unit tests most of the time because you're not going to know if your app or UI is broken otherwise. I tend to work in smaller teams where everyone is experienced, and use languages with decent type checking.

It's very possible to write great software without any tests at all too. It's like people forget that coders used to write assembly code without source control, CI, mocking and all that other stuff.

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

#229

Post by CJefferson »

gregthelaw wrote: post #166
ajross wrote: post #83

Earlier quoted context omitted.

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…

I've spent the past two decades working on a time travel debugger so obviously I'm massively biassed, but IMO most programmers are not nearly as proficient in the available debug tooling as they should be. Consider how long it takes to pick up a tool so that you at least have a vague understanding of what it can do, and compare to how much time a programmer spends debugging. Too many just spend hour after hour hammer…

I find the tools are annoyingly hard to use, particularly when a program is using a build system you aren't familiar with. I love time travelling debuggers, but I've also lost hours to getting large java, or C++ programs, into any working debuggers along with their debugging symbols (for C++).

This is one area where I've been disappointed by rust, they cleaned up testing, and getting dependencies, by getting them into core, but debugging is still a mess with several poorly supported cargo extensions, none of which seem to work consistently for me (no insult to their authors, who are providing something better than nothing!)

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

#230

Post by sitkack »

deepspace wrote: post #226
fud101 wrote: post #221

Earlier quoted context omitted.

i'm slogging through zen, it's a bit trite so far (opening pages). im struggling to continue. when will it stop talking about the climate and blackbirds and start saying something interesting?

Yes it starts slow, but keep at it. It starts to get interesting about halfway into the book, if I remember correctly.

One also doesn't need to enjoy something to get something very worthwhile out of it. Not apologizing for Zen, but all books have rough patches to someone.
Post reply on HN