Tag Archives: software development

“User Stories”

I’ve noticed recently people writing “User stories”. Examples: GNOME, Xen, Fedora doing something similar.

These are IMHO lazy, unscientific nonsense. For a couple of reasons:

  1. Unless you have done usability studies and surveyed real users, you have no idea what users want from your software.
  2. There’s no closed loop: You have to evaluate at the end of development how successful you were at meeting the needs of each user in each story. But no one is doing that, so they have no idea if they were successful or not.

I’d say this is yet another example of how software development really needs to grow up and become an actual engineering discipline.



Filed under Uncategorized

Don’t use release candidates, use stable branches instead

A lot of free software projects do release candidates, so you’ll see 1.9-rc1, 1.9-rc2, 1.9-rc3, …

I have never thought these were a good idea.

You are relying on getting testers, but getting people to test things is difficult (because it’s boring and hard). When you finally release 2.0, it’s like you’re declaring there are no bugs. Given that (a) software is intractably hard to test and (b) it’s hard to get testers anyway, it’s unlikely that 2.0 will be bug free.

libguestfs takes what I think is a better approach. In 5 days time I will fork whatever we have in development and I will declare it stable branch, release 1.12.0. That’s not going to be a stable version, and we don’t pretend it is.

Over the days, weeks and months that follow, we backport patches to the 1.12 branch, following rigorous rules. This makes the stable branch more stable over time. It converges on greater and greater stability as we fix more bugs, more conservatively. In libguestfs, some branches get fixes for 7 months and counting (git shortlog).

The elements that I think are important:

  1. Don’t do release candidates
  2. Don’t rely on getting testers
  3. Do use stable branches
  4. Don’t develop on the stable branch (develop on the head and backport)
  5. Do have strong rules about what you backport
  6. Do backport conservatively, and be more conservative over time
  7. Do use git cherry-pick!


Filed under Uncategorized