2006-09-14

Ultimate Quality? What's That?

I hack on the Twisted project. I have for years now. I only just found out I have a jerub@ email address there. I've had that for years too. I've been a lot more active lately than previously. I've got pypy running the unit tests, and I've been doing the odd code review.

Twisted has a development structure that I'm growing quite fond of. The idea is to produce code that we can call the 'Ultimate Quality Development System.'. Sometimes it feels like everyone is going on a health kick, all at once. Everyone's going to the gym, working out, doing all the right things, and when someone does something wrong (eats a hamburger) they get pounced on.

What does UQDS mean? It means that we have a software process. Not just a bunch of people who commit to our SVN repo. How does it it work? Well the process looks like this:

  1. Ticket is raised in the tracker.
  2. One or more people work on this ticket. They will accomplish the task set out in the ticket (be it Task, Enhancement or Defect)
  3. A person other than one of the developers from the previous stage reviews the changes. He may reject the changes or accept them.
  4. Then, and only then, do the changes get committed to trunk

What this means in real terms, is that folks say, "Why do I need to go through this process, it's an obvious fix for an obvious bug, a one liner."

An example that comes to mind that was a real situation that happened recently. A bug was reported, the fix was given, after referral to the bag tracker and the development process a test was also given. The ticket reached review, and I reviewed the ticket.

After reviewing the ticket, I made a branch (combinator is great for python/svn work), applied the patch with the test in it, fiddled around so the test was in a more appropriate file, changed the test so it tested the abstract base class (because that was where the code being tested was defined), wrote two more tests and found another bug.

That's why UQDS is awesome. Trunk isn't allowed to be changed without it being reviewed, and reviews find bugs. It was just a 1 line obvious change, and there was nothing wrong with the change, but by putting it through the formal process someone eyeballed the code a bit deeper than it had been eyeballed previous and another bug was found.

The idea is to never let code into trunk that hasn't been reviewed and passed on. Even trivial docbugs get reviewed, and even those trivial docbugs reviews find more things that need to be fixed, and the review will either issue another ticket, or block the merge until the problems are fixed.

This process exists in other places, but I've never seen it taken so serious as in twisted. Nor so successfully.

No comments: