Alan Cox on Writing Better Software

Andy Gimblett writes "Alan Cox recently gave a talk in which he discussed some current and emerging techniques for producing higher quality software. Some of these will be familiar to Slashdot readers, such as validation tools, type checking, etc, but others seem heavily influenced by his recent MBA. In particular, he has a lot to say about Quality Assurance in the software world, and the kinds of things we should be doing (and some people are doing) to make better software. Story and lots of quotes at Ping Wales, and video at IT Wales."

Comments

Re:Code review and pair programming

[ZorbaTHut]

Funny, that. I recently started working at a company with mandatory code reviews. Here's a list of my recent experiences with it:

1) Checked in code. Spent fifteen minutes justifying design decisions. No changes made.

2) Checked in code. Code contained horrible horrible bug. Code reviewer didn't see it.

3) Checked in code. Defended my design against several more computationally expensive suggestions that were also more complicated. No changes made.

4) Listened to a friend gripe about having to spend a DAY AND A HALF repeating design reasons and fixing bugs introduced by his code reviewer "cleaning up" his code.

5) Received company-wide email about a build that flat-out didn't compile - apparently someone hadn't bothered compiling a patch, and had sent it to a code reviewer, who likewise hadn't bothered compiling it before authorizing it.

Now I'll admit that there are also a whole lot of "well, it only took five minutes, so it wasn't much of a waste" cases. But so far I haven't heard one person talking about how useful the mandatory code reviews are.

Maybe it's just an artifact of the kind of programmers working at this company, or the kind of code being worked on, but so far code reviews have been a net loss in my experience. I've taken to doing major changes in my own personal branch of the repository (which doesn't enforce the code-review requirement) and in a month or two I'll have 3000 lines of code for someone to look at - but at least I won't have nickel-and-dimed them to death with 120 100-line code reviews, 3/4 of which I will inevitably end up deleting entirely.

Note that I'm not saying "code reviews are bad" - what I am saying is that there's a time and a place for just about every technique, and there's also a time and a place where each technique is worse than useless. Pick your battles and pick your tools.