Subversion Grief and Usability Testing

I sat down yesterday morning to work through the first half of the warmup exercise we've given the Hippo students. My goal was to have Hibernate persisting my book loan records by the end of the day.

Didn't get there. Instead, at some point I used Subversion's "move" command to move files from one directory to another. From what I now know, this actually creates a branch inside the repository. The visible effect is that when I add or modify files in one directory, do an "svn commit", and then do an "svn status", it shows my "bin" folder as being branched, and (this is the spooky bit) copies source files from "src" into "bin". This is a Bad Thing, and I am Unhappy. (I believe the capital letters are merited.) What's worse, I can't figure out how to undo it. I have even deleted my working copy of the repository, used "svn rm" to delete my personal sub-directory from the repo, and re-created everything, to no effect.

Michelle Levesque eventually pointed me at this section of the Red Bean book on Subversion. The key phrase for me is this:

At first glance, the answer may seem obvious: just compare the latest trunk tree with your latest branch tree. But beware—this assumption is wrong, and has burned many a new user!

Um, question: if the way you do things burns many new users, then why don't you change the way you do things? I don't know the details (yet), but I'm 99% sure that the reason this potential for burns exists is that Subversion's designers made one technical decision over here, and another over there, and only later realized that the collision between the two resulted in what Brooks called "accidental complexity", i.e. made something harder than it needed to be. (I know it doesn't have to be this hard because it isn't in Perforce.)

Now, if software had to meet the same standards as children's toys or automobiles, its designers would be forced at this point to go back and re-think the things that led to the potential burn. "Having the duck's head pop off is really funny, but a two-year-old might swallow it… Let's see what else we can come up with." Not software, though; you can do pretty much anything with software.

The situation is exacerbated by the fact that even systems intended for widespread use, like Subversion, are only usability-tested by their authors in the early stages of their development. By the time users like me get them, their author have internalized and rationalized traps like the one I stumbled into, or say, "Yeah, I know, but it's too late now."

And no, more documentation is not a solution. I can't count how often I've heard developers say, "But it's in the docs—jeez, we spent hours writing the docs, why don't you read them before you start doing stuff?" The answer is that you have to build things for people as they are, not as you wish they were. As a friend of mine who works in public health says, abstinence is not a practical cure for HIV/AIDS, because in practice, people won't abstain. Similarly, if you're billing your version control system as an easy step up from CVS, then you must design it on the assumption that most of the people using it won't read beyond the first half page of documentation before starting to run commands.

This is the main reason Hippo's user interface is so conservative. I'd like to experiment with weblogs for project management instead of mailing lists, and with wikis for bug tracking instead of database systems, but it would take half a dozen iterations over two or three years to come up with interfaces that newcomers in a hurry would be able to use without an unacceptable amount of grief. I don't like tree displays of threaded mail conversations, but everyone we're trying to reach is already familiar with them, and there are literally hundreds of systems out there from which we can draw inspiration. In the end, it won't matter how many cool things Hippo can do: if ten percent of its users lose an afternoon because a seemingly innocuous command has done something unexpected that they can't immediately figure out how to unwind, we will have failed.