A Requirements Challenge

I have always done highly iterative development and have always worked in short iterations. Initially this was because the domains I worked in early in my career gave me no choice but to work that way. Later I discovered the philosophical reasons for working this way. I also soon learned that keeping the software close to bug free was best. This was all back in the 1980s and early 1990s.

In 1992 I started Mountain Goat Software to do outsourced, contract development projects and needed a name for the new company. I found the name in Tom Gilb’s wonderful Principles of Software Engineering book. Every page or two has a gray sidebar highlight some key principle. On page 99 is the Mountain Goat Principle: Take one step at a time up the slippery mountainside, and make absolutely sure that each hoof is on solid ground before you take the next step. I’ve always considered Tom to have been the original agilist.

In 1989, he wrote about short iterations (each should be no more than 2% of the total project schedule). This was long before the rest of us had it figured out. Although I’d named the company after one of Tom’s principles, I had never met him in person. Well, last month I finally had the honor of meeting Tom and his son, Kai Gilb, who is a top-notch software consultant in his own right. (See Kai’s book on the Evo process). At dinner, Tom and Kai posed a challenge to me that I haven’t been able to figure out yet. We talked about how adding a new feature to a product is not an issue of adding new capabilities as much as it is about changing how well something can be done. I other words, it is about changing the quality of the implementation.

For example, imagine a simple word processor back in 1982 without an integrated spell-checker. Spell checking was still possible. You could have looked up each word on the screen in a physical dictionary and determined which were misspelled. Adding the integrated spell-checker was more about improving the quality of an implementation than about adding a new capability. The challenge that Tom and Kai posed me was to think of a function in MS Word (any word processor will do), that is a new function, and not just a change in the quality of those functions. To think about this, compare Word of today with the tools of a century ago—paper, pen or pencil, the post office, and so on. Surely, they were nuts, I thought. So I tossed off a few answers: “Undo.” “No,” they replied. “That could have been done in the old days with an eraser.” “Printing.” “No,” they replied. “That could be done by monks in a monastery making copies by hand.” I tried a few more but came up empty.

So, how about it? Can you help me by coming up with a feature in a word processor, like Microsoft Word, that is new functionality and not just a change in how well something could have been done with pencil, paper, and similar tools.