It's an obvious thing to check if you suspect it. If you're just reading code with no reason to suspect it has changed recently you might not bother to look.

This should have been the clue:

> The call to fork() did check for a -1 and handled it as an error and bailed out. So how was it somehow surviving all the way down to where kill() was called?

If the source code doesn't match the observed behavior, you should suspect the code changed.

Eventually she got there. There were a lot of other possibilities: maybe there's another place where kill is called; maybe the `kill` hypothesis is wrong; maybe something weirder is happening. Getting back to "oh maybe that's not what the code looked like back then" would likely take some further time.

I would think the default assumption for a large codebase is that the code changes regularly. And especially if you are looking for a bug that started after a recent push, checking the revision history seems like the very first place you'd look.

In this case the code went from bad -> good. The bug had existed for a long time before it finally got triggered in a catastrophic way. Even a large codebase has parts that are relatively stable. `fbagent` in this situation was a service responsible for gathering metrics, which is something that doesn't need that many changes (relative to, say product code) to it once it works.

> In this case the code went from bad -> good.

That doesn't matter, the code changed. It's not like you can know what effects changes had before checking whether changes occurred.

> The bug had existed for a long time before it finally got triggered in a catastrophic way.

The issue isn't missing that one bug, it's not realizing that the code you are looking at isn't the version of the code on the affected machine.

> Even a large codebase has parts that are relatively stable. `fbagent` in this situation was a service responsible for gathering metrics, which is something that doesn't need that many changes (relative to, say product code) to it once it works.

Clearly changes were nevertheless happening. I don't care if you're dealing with a COBOL program that hasn't been updated since the 80s - if you have a problem now, I just don't see any reason why you would ever not check the revision history.