They Eat Their Own Dog Food

Surprisingly, Wikipedia does not offer an exact origin to the term 'eat their own dog food' but puts it vaguely in the 1980s. It's most common use now is in reference to computer software makers that use their own products like Google's use of their Open Office. I get evidence every day how few products are used, no less exhaustively tested, by the people who make them. Today it was my coffee maker.

I love my current coffee maker. It has a burr grinder integrated into it so I dump water and beans into the device and program it to have my steaming pot of Joe ready when I stumble out of bed. It is nearly perfection, nearly. The one flaw that makes me crazy is that the cover for the carafe is often difficult to remove. The affordances for turning are minimal so it can sometimes be a significant challenge to remove it. This was not a problem when the device was relatively new, it only happens after many uses and can be reduced, though not eliminated, by scrupulously cleaning it each day. I can't help but wonder how long they used the prototype before it went to production and whether any senior managers actually use the products they sell.

I find this problem in software all the time. You can tell when a product was made by committee and lacks a single, cohesive design. I believe it was Brooks who made the observation that a single unifying design is the single most important attribute for a software product to possess. Yet this may be one of the single most difficult attributes to quantify.

I had a difference of opinion the other day with someone who did not share my belief in the centrality of the user in software design. I found it odd since this is part of the Agile Manifesto and one of the big truths I've learned through hard won experience. I hope I can eventually drill down on this difference in viewpoint but for now I'll avoid speculating on its origin and instead elaborate on my own.

Without humans there is no software. Not simply because there is no one to write it but because there is no use for software. I am finding it harder and harder to maintain a bright line between hardware and software as the years go by simply because without hardware there is no product. While the products become more software-centric, it is a simple fact of physics that without the hardware to control, the software does nothing. It is not the software alone that solves the problem set at the designer's door but the system of hardware and software than creates the solution.

Navigating from the solution space to the design space has always been a challenge. I think Christopher Alexander's work illustrates the challenge as well as anyone. The client engages professionals to perform this navigation on their behalf because this is a challenge that requires extensive education and experience to do with any level of predictability. Where I see the biggest challenges is in the work to define the boundary between this problem space and the solution space. At this border we see two vital artifacts in the SDLC, the requirements and the specification. Well done, the requirements document is completely agnostic to the solution that will be employed. A good specification document will define the solution that will exactly mate to the problem space with no gaps or overlaps. So much for theory.

Requirements suffer from many shortcomings. One in particular is the ability to anticipate every question a designer may ask about the problem. Even one attribute that is required for a good product to meet the needs of the client can result in the development of a sub-optimal solution. These qualities of software-in-use have been notoriously difficult to pin down. Take my coffee maker as an example.

The qualities of a software product as it is used over time are often overlooked in software development products. The focus is always on the present and the foreseeable future. Often what is foreseeable is surprisingly nearsighted. Just as my coffee maker's maker erred in not testing the product over a sufficiently long enough time to discover how the oils and acids of the coffee would affect the seal, so too most designers are so consumed with getting the most obvious qualities of the product right that secondary affects are often overlooked. These affects do not assert themselves until some time after the initial development team has been disbanded and the product is now in the nebulous world of maintenance. I can think of many instances of the same error in design that I now know to look for but which still must be taught to each new designer.

Putting data into a data store is a fundamental need in most any business system. What is less obvious is that eventually data must be taken out lest the data store changes its quality. Here I mean quality to mean mean-time-for-retrieval, backup time or some other quality dependent on scale. A database table can use an index to speed retrieval but the need for that index is often overlooked when the table has not yet grown to its steady state size, or worse when no provision to remove has been made. In this case the effects of scale will slowly creep up over the life of the product until a response is forced. It's easy for me to clean my coffee pot and see the relationship between use and action that will return the product to its original function. Not so with a complex system.

This is where "eating your own dog food" has its advantages. At worst, you are learning the latent defects of the product in parallel with the maker. But the difference is that a business dependent upon the same product you are is likely to be more attentive to the dangers of a latent defect than one that is merely providing a product to a marketplace. The first can perceive an existential threat while the second merely a potential threat to their market position. This is where I see the open source movement to derive its greatest motive force. People contributing to open source projects more often than not are dependent upon these software products and highly motivated to make them easier to use, more robust and to more nearly solve the problems that they have as people in the service of a larger organization.

Open source developers consume their own products most often because for them they are their tools. Every worker yearns to be able to craft the tools that will make their jobs as easy as possible. As a child, I had briefly apprenticed myself to a retired Danish cabinet maker who was using my idle time to help him with his work. He told me, "never stand when you can sit, never sit when you can lie". He taught me how to make jigs to help with the repetitive work we needed to do and many other ways to simplify by employing tools. Software work is no different than wood work in this regard. The market place has provided many good tools but the need to define and even build our own tools has always been there and only we know how our needs grow and change over time. Software development is less often a solo activity than popular images suggest. And the tools that are needed when programming in the large are very different than programming in the small. But the open source movement has allowed alienated developers who share these unfulfilled needs to band together into functional organizations that can effectively create the solutions that they know are needed removing intermediaries such as third parties or markets.

If end users could directly program their own devices, the need for systems development as a work for hire would not exist. Despite some improvements in end-user computing, it does not look like this will change soon. Clients will continue to be dependent upon software engineers to create their systems. If developers have had such a difficult time elaborating on their needs so as to create such a vibrant and productive movement in open source software, what hope is there for clients? Is it a realistic expectation that clients can articulate their problem space to such detail that a designer with less than perfect knowledge of their point of view can create a specification so perfect that the product will be right the first time? This implied water fall thinking is a major contributor to the Agile Manifesto and the central need for iterations. Rather than blame the client because they neglected to mention something, make them an integral part of the process and accept their shortcomings just as you expect them to accept your shortcomings when the final product is found to have defects that are traced to your own failures. And please stop calling them bugs. They did not fly through the open windows and ruin your perfect program. They are there because of some failure of communication or logic.

So having clients intimately involved in the development process is a hallmark of a successful project and an indicator of why open source software is often so successful at creating good products. If the developer and the client are one in the same, you cannot keep them out of the process. In the world of commercial software development, it is still too common to see the client's voice marginalized and I believe this is one of the great sociological challenges faced by software engineering today.