Eat your own Dogfood

I spent the day helping a client set up a software system to help them keep their bank accounts reconciled. It was a ridiculously frustrating experience. The idea behind the software package is that now that most banks have web sites where you can download a file containing the account activity, it should be simple to pull a new file down every day and constantly make sure that you and the bank are on the same page about how much money is in your account.

After spending most of the day at this, I feel pretty confident in saying that no one involved in building the software ever actually used it to reconcile a bank account. Technically, the software did do the things that its feature sheet claimed it did, but I don’t know that the user was any better off as a result of having it

I think that’s the problem with a lot of software design – people think about the data the software must track or process, without really giving much thought to the steps that the user will have to perform to use it.

My wife, before “retiring” to have babies, was an interior designer. After someone has determined the “features” a building will have (how many bedrooms, etc.) and designed it so that it won’t collapse, Interior Designers make sure that it “works”. Whenever I’ve been looking at a potential new office space and trying to determine what kind of build-out we need to do, I would drag her along and she would point out things like “this door can’t open this way because it would block the hallway when it’s open. It needs to open the other way.”

That’s exactly what’s missing in most software development today. The attitude is typically “the spec called for a door so we put a door there.”

As a programmer, I’m guilty of this. More times than I would care to remember, I’ve written a program for someone, sat down with them to show them how to use it, and almost instantly realized that the way I’ve designed it doesn’t make sense for how this user needs to use it. This typically goes something like this:

Me: You type the invoice number here to pull up that record.
User: I don’t know the invoice number at that point. I’m doing the data entry from this spreadsheet and it doesn’t tell me the invoice number. It does tell me the order number, though. Why can’t I just enter the order number?

People at Microsoft talk about “eating your own dogfood”. They practice this by using new releases internally before they are released to the public. Most of us don’t have the R&D budget that Microsoft does, but we need to spend more time thinking about how users are actually going to use the software we write, not just about what things it needs to do. Next time that you’re designing some software that a person will use, pay attention to which way the door opens and if it’s going to block the hall.

Alan Cooper (often called “the father of Visual Basic“) has a lot of wisdom to offer on this subject.