Comment by randerson

Comment by randerson 5 days ago

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 case we never found the bug, because we could only dedicate a finite amount of time to a "fixed" issue.

hughdbrown 5 days ago

> 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.

Reply View 3 replies

PaulHoule 5 days ago

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.

Reply View | 0 replies
yakshaving_jgt 5 days ago

I’m not sure it implies buying from elsewhere. I understood it to mean make a new one, rather than try to repair the broken one.

Reply View | 1 reply
- hughdbrown 4 days ago
  
  Let me reformulate then.
  Take the wikipedia article on debugging[1]. The first sentence identifies what debugging is: "In engineering, debugging is the process of finding the root cause, workarounds and possible fixes for bugs." I'd say this is implicitly about taking broken code and finding the error in it.
  The second paragraph is clearer on this point:
  > For software, debugging tactics can involve interactive debugging, control flow analysis, log file analysis, monitoring at the application or system level, memory dumps, and profiling. Many programming languages and software development tools also offer programs to aid in debugging, known as debuggers.
  All of the debugging tactics listed are about working with an existing broken piece of code.
  Further sections on debugging tools, debugging process ("debugging process normally begins with identifying the steps to reproduce the problem"), and techniques are also about working with broken code.
  Completely rewriting the code is certainly a way to resume progress on a software project, but as the practice of debugging is imagined, rewriting is not debugging.
  [1] https://en.wikipedia.org/wiki/Debugging
  
  Reply View | 0 replies

eru 5 days ago

Depending on how your routine looks like, you could run both on a given input, and see when / where they differ.

Reply View 0 replies