The true story of what was

I was poking a longstanding minor niggle in anaconda today, and it made me think about one of the principles I've come up with over the years I've worked on bugs, in various capacities.

To put it simply: it's often important to know the story of why something came to be the way it is. Just knowing that something is a certain way, and perhaps believing it should be otherwise, is frequently an incomplete position.

In the case of the bug above, without the historical context which is somewhat covered in the bug, maybe you'd read the dialog, and notice that the options mentioned in the text and the buttons at the bottom don't really seem to match up. You might even make a guess at why. But it helps a lot to understand the full context.

In this case, the text is from a previous incarnation of the same dialog, when the flow through the various possible paths of the partitioning UI was somewhat different, and different buttons were available in the dialog. It's pretty useful to know that the workflow changed around the text, rather than vice versa, or the text simply being written wrong, or a bug preventing the right buttons being shown, or any one of a thousand other ways the same situation could result.

I've come across many other cases like this; this is just one example. These days, when I come across any bug which is broadly a question of some kind of designed behaviour being odd - not simply a straightforward 'this app crashes when I do X' type of bug - my approach looks something like this:

1. Check if someone already reported the issue and if so, pick up that report, don't start a new one (this is always step 1).
2. Check the documentation. (This is always step 2).
3. Find the code that implements the behaviour, and read it. Yes, even though I'm really not a hacker. Always try this. Frequently, the kind of code that implements behaviour choices will be understandable, at least broadly speaking, to anyone with a rough understanding of how computers work, and if you're lucky, there might be an explicit comment explaining exactly what's going on, put there the last time someone asked.
4. Check the context and the history of the code. git blame is one of the greatest inventions ever, for this - not literally because it tells you who made the change (usually), but because it gives you the commit. Use git blame, read the complete commit, and read the commit message. Check the date on the commit, and go read the project's mailing list (or whatever publicly archived discussion format the project uses) from around that time; there may well be ancillary discussion there. Read around the area of code in question, it may matter. Follow the trail wherever it leads - go check other functions up/downstream of the one you started at if necessary, look back through multiple git revisions, just keep asking "why does this behave the way it does?" until you think you have a complete answer to the question.
5. If you can't manage to work it out from the code and the public records you can find, go find the relevant people, and just ask. If you know them already (and they don't hate you), this step should be easy. If you don't, it's still easy. Just drop an email to the address associated with the commit, say "hi, I'm Bob, I'm looking into this bug (URL) for this project (URL), it seems to be related to this code change you made back in 2008 (commit link), and I couldn't quite figure out why you wanted it to behave this way - could you help me out?" Usually, if you're polite and provide a full explanation of why you're asking, people will be happy to help.

I always find it fun when disciplines overlap in interesting/unexpected ways. As I've probably mentioned a few times, what school background I have (a glorious bachelor's degree!) is in history, which doesn't seem like it ought to be that relevant to the work I do now. Frequently, though, there's more of an overlap than you'd expect. This is one obvious example.