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

DiffDebugging

martinfowler.com

Post reply on HN
Print view View original

31–40 of 43 posts

Re: DiffDebugging

#31

Post by pnt12 »

theyinwhy wrote: post #22
pixel_tracing wrote: post #10

A well known very large successful trillion dollar company emphasizes this heavily and it’s called identifying Cause By, regressions are categorized before a build is submitted, in the current build, or in previous builds. It’s extremely important to identify cause by (commit) in order to either revert or fix.

Sounds interesting. Could you elaborate, I don't quite understand it. You test for regression errors before commit? But why commit with known regression errors?

Maybe they test (with code or manually) different commits and then point out which one introduced the problem in the ticket system.

Could be useful but parent mentions a megacorp, so maybe it's just some bureaucracy or ball-breaking.

Re: DiffDebugging

#32

Post by pnt12 »

heads wrote: post #23
juped wrote: post #19

Note that when (other people's, surely, not yours) bad git history with unrelatedly-broken commits everywhere means you can't bisect, you can use bisect --first-parent to travel down only the first-parent history (which should be just merges to master) rather than having to laboriously figure out whether it's "bad" or "skip" this time. If you're unfortunate enough to have an impoverished "linear history", you're stuc…

The usual definition of “linear history” is equivalent to what you see with “git log --first-parent”. Linear history doesn’t mean that people share every “wip” commit from their private feature branch with everyone else. With linear history you squash everything into a single, working commit which is applied to the tip of the shared branch. The rationale is that each change is like a published piece of writing: it wi…

Very well put. This is the work flow which has worked best for me over different teams.

An opposite which I could accept is asking people to carefully rebase their drafts, but I see it as a higher effort with a bigger risk of screwing up, with a dose of bikeshedding an additional topic, the commit history: "why do you split in 5 commits when 2 would be enough?"

I guess you can keep the drafts if you don't delete feature branches. But I don't see it as extremely useful, unless it's a very talented individual AND very methodical with his commit history.

Re: DiffDebugging

#33

Post by spudtrooper »

theyinwhy wrote: post #22
pixel_tracing wrote: post #10

A well known very large successful trillion dollar company emphasizes this heavily and it’s called identifying Cause By, regressions are categorized before a build is submitted, in the current build, or in previous builds. It’s extremely important to identify cause by (commit) in order to either revert or fix.

Sounds interesting. Could you elaborate, I don't quite understand it. You test for regression errors before commit? But why commit with known regression errors?

As a previous comment said, this sounds like a generalization of regression testing. This article seems to focus on the small scale and omits a couple points relevant to larger scale systems:

- data dependencies cause regressions, so you. need some way to factor this in - production changes cause regressions - debugging at the source code level can be laborious past a certain point

The way I approached doing this at another (maybe same) T$ compnay was tooling that could take anything observable -- e.g. logs, program traces, signals from services, service definitions, data, stack traces from debuggers for side-by-side running -- convert it to a normal form (e.g. protobuf or JSON) and then diff that to look for regressions.

Re: DiffDebugging

#34

Post by The_Colonel »

48864w6ui wrote: post #28

Why is this general technique worth a blog post by someone who makes his living coaching working programmers, and not taught in elementary school? (To be fair I think the first time I heard it explicitly from a teacher was Jr high shop class) Edit: at what age do people usually learn to play 20 questions?

Many working programmers don't know / use this technique. I bet it was even less used 20 years ago, it took a while till people realized what a revision history could be used for.

Even if people know / use it intuitively, there's a value to describe it more formally and give it a name.

Re: DiffDebugging

#35

Post by The_Colonel »

nerdponx wrote: post #14
ajb wrote: post #5

A more generic term is "delta debugging", which has been around for a while. git bisect is one example of a tool which does it, another is Zeller's DD tool https://www.st.cs.uni-saarland.de/dd/ It's also possible to do this is a Bayesian fashion.

I'm very curious in the Bayesian approach to bisect debugging. Got a reference?

My guess would be that you don't always use the middle of the interval, but choose knowledge of the history to guide your choice of the tested revisions.

e. g. recently I was debugging a problem, after two halvings, I saw there's a big refactoring in the remaining interval, so I picked the revision before/after.

Re: DiffDebugging

#36

Post by 48864w6ui »

The_Colonel wrote: post #34
48864w6ui wrote: post #28

Why is this general technique worth a blog post by someone who makes his living coaching working programmers, and not taught in elementary school? (To be fair I think the first time I heard it explicitly from a teacher was Jr high shop class) Edit: at what age do people usually learn to play 20 questions?

Many working programmers don't know / use this technique. I bet it was even less used 20 years ago, it took a while till people realized what a revision history could be used for. Even if people know / use it intuitively, there's a value to describe it more formally and give it a name.

20 years ago, at least in my circles, it was ubiquitous. Because we did it manually, no one had the time to linearly search out a regression.

(BTW sccs was 1972; no doubt it had predecessors. Before disks were large enough to hold multiple versions of a source tree we kept them on tape)

Re: DiffDebugging

#37

Post by mettamage »

I have done poorly thought out versions of this. Reading this will make me a better programmer. I didn’t know much about git bisect. Will play around with it.

It’s magical to experience a short but sweet tip and you just _know_ that (programming) life got a bit easier. Good bang for buck blog post! A few minutes well spent.

Re: DiffDebugging

#39

Post by gcarvalho »

bad_username wrote: post #24

The culture of rebasing and squashing is the enemy of DiffDebugging. When you squash, you make your deltas very big and less useful. When you rebase, you generally lose your deltas completely, because a rewritten history consists of commits nobody generally tried out.

> a rewritten history consists of commits nobody generally tried out

I find the exact opposite to be true.

When you merge 20 commits from a branch, you add to the history a bunch of unfinished-state checkpoints, which may not even compile individually, and that may make the search longer than it should. Also, those intermediate commits probably never were deployed as individual units.

In a merge-squashed main branch all commits:

* were reviewed as a single unit, but may have originated from multi-commit branches

* are guaranteed to have passed the test suite

* by definition, are at a ready-to-deploy state, even if they contain feature-flagged components

These are much easier to bisect through. And their changeset shouldn’t be any larger than any regularly-merged branches. It’s the same unit of work, merged differently.

If the PR is too large, then you’re probably lumping too much stuff together, which also leads to slower and worse code review cycles.

Re: DiffDebugging

#40

Post by broast »

pnt12 wrote: post #30
broast wrote: post #11

Earlier quoted context omitted.

Right, this is the common sense approach for identifying the cause of a regression. Not sure what people do other than this unless it's a very simple codebase

I don't see this technique applied too often. I see more often: - reading the affected code - reproducing the problem step by step with a debugger Which I guess works for all kinds of problems and not just for regressions, therefore people are more used to it?

My thought is in a complex system the cause of the regression is not usually near the point of failure, so debugging can become unmanageable without the upfront effort of identifying a small set of changes that might be responsible, so you have some more places to set your breakpoints.
Post reply on HN