Pass the dogfood

Eric Sink wrote a blog post differentiating between different approaches to software development, (linked, and summarized, by Jeff Atwood of Coding Horror), mainly questioning how developers are using the own products they develop. The two interesting commercial categories are “ThemWare”, software that is not used by the developers themselves, and “UsWare”, software which is used internally, and thus is far superior. Jeff writes:

Consuming the software you’re creating is colloquially known as dogfooding in programming circles. Unless you’re (un)lucky enough to be writing software intended for other software developers, dogfooding can be a challenge.

“Eating your own dog food” is indeed a good practice. It keeps you in tune with your users. It makes you look at things from their perspective. And we do that a lot here at RADVISION. Many products are created over other products in a big happy food chain: the TBU (Technology Business Units) creates the protocol stacks and frameworks, the NBU (Networking Business Unit) builds products over the protocol stacks and frameworks, these products are integrated into RADVISION’s network, and all the employees can make global video conferences using in-house technology. What can go wrong? Eric writes:

I think dogfooding is one of the most important things a developer can do. Nothing gets you closer to the perspective of your users than becoming one of them. But UsWare still has challenges. Your users are still probably not exactly like you.

This is the main problem with the way we “eat our own dogfood” here at RADVISION. We ARE exactly like us. Our customers are not. When our products travel our cozy little ecosystem, they are treated nicely wherever they go, cooperate with similarly written software and are sheltered from the rough handling of programmers who are not “in the know”.

Take H.323 for instance. The product has been around so long it has become nearly foolproof. Nevertheless, I got support calls lately, and both share the same traits: people treated the stack badly. It really did want to work, the poor thing, but the threading model was all wrong, and the access was so harsh. If only the developers in that other company were more like us. Of course, we should have thought of that. Maybe put a note in the documentation that such a threading model required some additional work. We didn’t because we think like us, not like any programmer out there. You see, to paraphrase Tolstoy, user experiences are all alike; every developer programs in his own way.

We are unlucky enough to be writing software intended for other software developers. What do we do to stay alert?

• Cooperate
  Some customers just know better. Many times, our partnerships with other companies lead us in ways we would not have thought of going ourselves, both in matters of features and of design.

• Adapt
  Our customers are developers, so naturally we have some common ground. They detail their expectations when using our code, and how these expectations were met (or not). We do our best to make the customer’s experience better.

• Introduce new paradigms
  Since our teams are dynamic, there are new recruits and people moving between projects and teams. New eyeballs see things differently, and sometime they question the way we do, or do not, do things.

• Use, learn, refine, repeat
  New projects are built over older projects, because additional features are required and a more specialized API is needed. For instance, the Media Terminal Framework is built on our SIP stack; the new V²oIP engine is built on top of that. The MTF is simpler to use than the SIP, and the V²oIP engine is even simpler (albeit more limited) - each level sets out to solve issues encountered with the one below it.