Using our own tools / means and ends

[20 April 2008]

One often hears, in information technology and in spec development, the injunction to eat one’s own dog food, meaning to use, oneself, the technologies one is developing. By confronting the technology as a user, the designer will become aware sooner of flaws in the implementation, gaps in the functionality, or other usability problems. I hate the metaphor, because I don’t think of the technology I work on as dog food, but it’s good advice.

I’ve been thinking lately that I should be making a lot more use, in my work, of the technologies I’m responsible for. There is a radical difference between the attitude of someone who has designed a system, or engaged with it as an object of study, but never much used it, and someone who has actually used the system to do things they wanted to do, treating the system as a means not an end in itself.

I once sat in working group meetings listening to brilliant computer scientists telling us how the working group should approach various problems, and being struck by the fact that if they showed five XML examples of two to ten lines each, at least two of them would be ill-formed. They had a pretty good theoretical grasp of XML, although they didn’t grok its essence. But their mistakes showed clearly that they had never spent as much as thirty minutes writing XML and running it through a parser. It was no wonder that their view of markup was so different from the view of those of us who worked with markup during most of the hours of our working lives. To them, XML was an object of study. To those of us who actively used it, it was no less an object of study, but it was also a means to achieve other ends. I mentioned to one of the computer scientists that the well-formedness errors in his examples made it hard for me to take his proposals seriously, and to his great credit he did address the problem. He never showed an example in XML notation again; instead he wrote everything down in Haskell. (And since he used Haskell more or less constantly, he didn’t make dumb syntax errors in it.)

In practice, I think the ‘use your own tools’ principle means I should spend some time trying to upgrade my personal tool chain to make use of technologies like XProc and SML. (There are some other technologies I should make more use of, too, but I’m not prepared to identify them in public.)

At the same time, I’m also acutely conscious of the difference between experimental systems and production systems. Experimental systems need to be able to change rapidly and radically as we learn. Production systems need to be stable and reliable, and cannot usually change more quickly than the slowest user who relies on them. The maintainers of a production system seldom have the ability to force their users to upgrade or make other changes. (And if they succeed in acquiring it, they will be regarded by their users as tyrannical oppressors to be deceived and evaded whenever possible.)

Specs in development sometimes need to be experimental systems.

Some people will say no, never standardize anything that requires experimentation: only standardize what is already existing practice. The example that sticks in my head from long-ago reading on the theory of standardization is machine-tool tolerances: if no one sells or buys tools with a given tolerance, it’s because either there’s no market for them (so no need to standardize) or no understanding of how to achieve that tolerance (so a standard would be pointless and might get crucial bits wrong out of ignorance); standardize the tolerances people are actually using and you’ll produce a standard that is useful and based on good knowledge of the domain. This principle may well work for machine tools; I am not a mechanical engineer. But if you wait until a given piece of information technology is already common practice, then by and large you will be looking at a marketplace in the form of a monopoly with one player. If you’re looking for a non-proprietary standard to provide a level playing field for competing implementations, you’re too late.

In information technology, standards that go out in front of existing practice appear to be the only way to define a standard that actually defined a non-proprietary technology. Ideally, you don’t want to be too far out in front of existing practice, but you can’t really be behind it, either.

If you’re out in front of well established practice, the spec needs in some sense to be experimental. If the responsible working group finds a new and better way to say or do something, after issuing their second public draft but before the spec is finished, they need to be free to adopt it in the third working draft.

If I rebuild the tool chain for the XSD 1.1 spec to use XProc, for example, that would be interesting, the re-engineering would probably give us a cleaner tool chain, and it might provide useful feedback for the XProc working group. But when the XProc working group changes its mind about something, and the implementation I’m using changes with it, then my tool chain breaks, and not necessarily at a time when it’s convenient to spend time rebuilding it. (Long ago, my brother was trying to persuade me I should be interested in personal computers, which I regarded as toys compared to the mainframe I did my work on. Nothing he said made any dent until he said “Having a personal computer means you get to upgrade your software when you want to, not when the computer center finds it convenient.” That sold me; we bought a personal computer as soon after that as we could afford one.)

Is there a way to manage the tension between a desire to use the tools one is building and the need for the tool chains one uses in production work to be stable?

I don’t know; but I hope, in the coming months, to find out.

5 thoughts on “Using our own tools / means and ends

  1. What dogfood manufacturer actually consumes his own product? The very idea is revolting, which is why I hate this phrase.

    Posix is, I think, a good counterexample to the notion that retrospective standards are necessarily proprietary. For that matter, so is XML 1.0.

  2. John, good points all.

    XML 1.0 can certainly be viewed as retrospective in many ways — certainly we tried not to do much new. But the particular combination of not-so-new features we adopted, and the many combinations we might have adopted had this or that decision gone differently, were none of them “established practice” as I understand the term. (Perhaps I didn’t understand that chapter on machine tools correctly.) So I think of it as a spec that standardized ahead of the market, not behind it.

    I’m glad you too hate the phrase. But we need a catchy alternative, and ‘using our own tools’ is not it. ‘Eating our own cooking’ is less stomach-turning, but also less vivid, and it feels derivative. I’d be tempted to adopt the neo-Stoic motto “Sei deine!”, but I don’t think that will fly, either.

  3. a few observations;

    * ‘I have heard it said that the best musical instrument makers are absolutely useless when it comes to making music.’ — unattributed quote
    Perhaps those who design systems or who are at the beginning of the food chain really are not interested in using computers like ‘users’ do.

    * and on the subject of eating food; I know quite a few professional chefs (including a michelin starred chef) all of whom eat the worst food when out of their restaurants … not sure if its the late hours (and the only place open is some bad fried chicken place) or if the cooks taste buds are seeking a shock 😉

    * as for specs, perhaps some of them start out ‘ahead’ of marketing curve … they have too … because of the time it usually takes to agree on a specification can take a number of years 😉

    * From a personal point of view; I find myself wanting to try out so many technologies/tools but I have learned to ask myself ‘what problem am I solving’ first …. if I have no ‘problem’ then I know I am not starting off in the right place to adopt any tool.

    cheers, J

  4. Browsing the Web this afternoon as a way of avoiding doing my weekend chores, I find an interesting formulation of a complementary (but not quite, I think, opposing) viewpoint in a recent entry in Jacek Kopecky’s blog Kopretinka. It is not at all unusual, he points out, for the object of our development work to be inapplicable to the day to day operation of the environment within which we live and work. He almost persuades me — and yet. And yet …

  5. Dear Michael,
    thanks for the comment. I knew(!) that I had read something about this not long before I wrote my entry, but I didn’t connect it…

    I wrote my entry as a reaction to one more call from someone for “them” to eat their own dog food, even though it was masquerading as “us”: a remote member of our institute was commenting that we in the institute are failing in this respect. There is a piece of truth in that, and there is also a piece of arm-chair quarter-backing present.

    Using our own technologies as we develop them would generally make them better, I agree wholeheartedly. Instituting requirements along these lines in standardization bodies would be an intriguing experiment, but in such a political setting, it might be dropped on a technicality.

    But criticizing others for not using their own technologies should be done after careful consideration. But then, I’d like all criticism to be done after careful consideration, so I guess there’s nothing new here…
    (I’ll also put this as a comment on my blog).

Comments are closed.