Suggestion for 'Don't blame the decaf: What really causes software failures (and successes)'

[humphd]

I really enjoyed this talk. I think one of its main strengths is that you employed a fantastic narrative style, and in doing so, put the problems of failure at arms length from the audience: it's much easier, or at least more comfortable, to learn from other's failure than our own. I liked how you also removed these issues from technology as such: the same problems happening with technology in the 80s is still prevalent now, since people still write software.

I have one suggestion, in case you give this talk again. You write:

Version control. Obviously.

I think, given what an excellent job you did elsewhere in this talk to help question the assumption that things are obvious, you should consider replacing this with an explanation. For someone experienced with version control, as I know you are, it is so obvious that one should use it that you can't imagine working without it. It's hard to imagine a situation where you'd need to explain it. And yet, my teaching has shown me the exact opposite.

I'm amazed every time I do my open source course at just how much time I end up needing to spend on this topic. I don't think there's anything obvious about it for students. They not only lack the knowledge of tools like git or hg, but more importantly, they often don't understand how to do work that fits nicely into a version controlled environment: what goes in a commit; how to handle concurrent changes to evolving software; when to update work to match upstream; how to deal with conflicting changes (I can't believe how often bugs slip in this way); what to change/not-change in a fix in order to avoid corrupting history; how to use code history to understand systems; what goes under version control, and what should get generated or stored externally. The list is incredibly long, and it definitely affects quality, security, and safety.

At any rate, I loved this talk. Thanks for putting it in git where I can leave a note of gratitude and suggestion.

[jorendorff]

OK, let's fix this.

It's hard to write a short explanation here, though. Brainstorming:

• Version control. That is, we use a system like Git for sharing code and tracking the history of our code. It records all the changes ever made in the project, who made them, and when. What does this have to do with quality?

  That history is really handy for anyone trying to fix anything. It's useful in many ways, large and small. Version control makes it easy to undo changes, for example. We also use it when we find a bug, to go back to older versions of the browser and see if they have the bug too. Often we can pinpoint the exact change that introduced the bug this way, even if it happened years ago. That makes the bug a lot easier to fix.

[humphd]

I think this looks good. As you point out, explaining this fully is beyond the scope of what you're discussing in this talk; but one more point you might want to discuss: version control allows Mozilla and other projects to actively delete code vs leaving things in "just in case." The reason I think this matters is that I have found people new to this kind of programming are really hesitant to remove things, to lose things. And yet removing code also removes bugs, and it's only because we can easily go back in time to resurrect something that we end up having this kind of confidence with the scissors.

[jorendorff]

Thanks, David.