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.
Tags: agile requirements
Seeing as Word is actually a copy/digitalisation of existing functionality, this will be a hard one, as you’ll have to come up with a new functionality on the whole (not just for Word) – proving the whole point of Tom and his son.
But I will let you know if I think of one (chances are small however
Auto-correct. Yes, you could go back and correct your own spelling, but here the feature takes the initiative and does it for you. There is no technology of 100 years ago (other than a human being) who could have done this.
For auto-correct, I believe the answer is that I could have hired a typist who corrected things for me as I said them. Or I could hire someone to watch me as I write and tell me when I make a mistake.
The thing is, you can’t change our basic human senses, which define the limitations of paper/screen style communication. This means that no matter how hard we try, we can only ever come up with ways of improving the economies of said communication, but we can’t actually define requirements that weren’t “technically” possible before.
Of course—to stretch one of your examples—could any monastery of monks mass produce a book? I don’t think so. We can argue that they can perform any piece of the copying process, just like our software alternative, but due to the economics, you would never actually be able to get them to do it!
What software does then is radically change the economics altogether, allowing us to do things that simple weren’t feasible before. Another interesting point then is what features have been added to word processors that allow us to do things so much more easily that we can afford to do them now. Like mass production, without even using paper!
On the other hand, depending on how picky we want to be, it could also be argued that a human being cannot create a “perfect copy.” This could be an actual addition. We also couldn’t effectively preserve documents before, they instead had to be copied, imperfectly, over and over again.
Lastly, there’s a more extreme example we could use here too. The Internet. Of course we could transmit messages before, but that’s a far cry from what we use today.
– Lorenz
Hi Lorenz–
Good points but if I can pretend to be an honorary Gilb for a moment, I think their answer will be that mass producing was indeed possible. That it never really happened doesn’t matter. Some 10th century king could have told a vast army of monks to produce 100 copies a day. So, me having a print button where I can type quantity=100 and getting those copies in 30 minutes is only an improvement in the *quality* of the function. The function (make multiple copies) is the same.
Transmitting messages over the internet (email) is again a quality improvement over pony express–it’s not a new function.
I’ve begun to get my head well around this distinction they draw. What I haven’t figured out is why it’s so important to realize that everything is a difference in the quality of a function rather than a new function itself.
Computers only carry out tasks which can described as a series of instructions. If it can be described then a human could do it by hand, probably more slowly.
The features are added to the human in terms of things that they would bother doing.
I will bother putting the ISBN number.
I will bother putting the exact coordinates
I will bother letting people know about this.
When we approach user central design in software development, it is vital that the function were mapped into a certain human behavior in his daily job. If there is anything that could not be mapped it might not be what end user really want, in another word, it might be waste. I feel like probably 99% of the function should come from real human behaviors. Given an example, if there is no CRM system, users still can use e-mails, messengers to do accomplish the same jobs. If there are no e-mails, messengers, users can still use mails, telephones to carry on the same jobs. The difference is how efficient by the way their jobs have been done. More people nowadays talked about that IT should always align with the business. I am thinking whether there is anything as an IT innovation could change the way of running business or human behavior which have never used by human-being before. The answer might be no. However if there is any, it must be an huge IT revolution.
Any great product (that MS Word definitely is) is inevitably a solution to a burning problem of many people (otherwise many people wouldn’t pay money for it). And if the problem was burning, naturally people had to have some workarounds for solving that until the great product arrived. Some products become great solution because of the excellent product management behind, some – by luck, but there had to be a serious problem behind.
Mike, when you are asking about a feature that was not a change of existing poor implementation, it sounds to me like you are asking for a feature that was solving no problem (or was solving it even more poor than the previous implementation). Looking at the list of never used MS Word features, I would give you a Clip adviser as an example. It solved no real problem (at least no top problem) without existing workarounds and therefore in a Gilb terms (as I understood them) Clip was probably a totally new (and therefore in the same terms “useless”) functionality
Hopefully Tom or Kai Gilb will chime in here and help clarify their position. But as I understand relative to what Pete and Artem just posted, it is not about doing something a human can’t or about adding something no one wants. Their point to me was that rather than thinking about “what new functions (features) should we add to this product?” the real question is about improving how well functions are executed. For example, even without email I can distribute a Word document widely–I can print it, put copies in envelopes and mail them. Having a built in “email this document” menu item is really then a change in the quality of the “distribute this to others” function” rather than a new function itself.
Both auto-correct and auto-save greatly improve the users experience in a way that can’t be done with paper, pencil, etc. In any case, at a more global level, SW is valuable because of efficiency gains for the user. Furthermore, SW provides a reduced cost to that efficiency in a way that a hired typist or an extra copy machine can’t. The key is that in the process of making the software work for everyone, you lose sight of the original reason for creating the SW in the first place. If there is no “right answer”, the need for SW wouldn’t exist.
The Gilbs seem to define everything that has been possible in the past, even theoretically, as not something new, but just an improvement.
Don’t you think that by defining the terms this way, everything will become an improvement, rather than something completely new, just by definition?
Mike,
“I’ve begun to get my head well around this distinction they draw. What I haven’t figured out is why it’s so important to realize that everything is a difference in the quality of a function rather than a new function itself.”
That’s my question as well: why is the distinction interesting?
Software developers have been doing the opposite thing for ages — “That’s not a bug, it’s a feature request” — and it’s not exactly helping the end result.
Trying to think of a “function … that is a new function” seems to me (as Artem suggested) like trying to invent a solution to a problem that doesn’t exist. It’s like the antithesis of software development. All the great developers I know are problem solvers. This is easier than the chicken & egg question, because in software development the problem HAS to come first. If there is no problem, then trying to think of solutions is an exercise in futility (unless maybe you’re a game developer, in which case you’re not initially trying to solve a problem so much as create fun, but the problems and technical challenges soon follow).
It seems like what you’re asking is, “What is a word processor missing?” Well, what does a word processor really have to do?
It’s a limited problem space. When you break it down to the essentials, a word processor doesn’t have to do that much, and all the bells and whistles are simply improvements on the handful of basic solutions that a word processor has to cover.
Seems to me that if by 2009 we haven’t covered the bases with a word processor – if it’s missing a feature that actually could be deemed as “new” – then we’ve royally screwed up as a profession.
It would not have been to track, accept and reject revisions from multiple people and see all of the multiple revisions together in a single document. Without “Word” you’d have to send a document to multiple reviewers. Then once you got it back, you’d have to create new documents with every possible combination of changes and annotations. You could do something that achieves a similar result, but for Word that will always true since Word is all about making paper documents – that is, making electronic a real-world thing.
Excel on the other hand…do a simulation requiring hundreds of thousands or millions of calculations by hand. It’s only possible in theory.
whoops, I meant, “I would go with the ability to track, accept…”
Perhaps online collaboration. Being able to work together on a document no matter where in the world you are.
Perhaps being able to send a crash report back to the dev team when the application crashes
Regards,
Joakim
I don’t think Tom and Kai are saying that everything that can be done has already been done. There certainly not saying that we don’t need software. Their point is that in specifying a product we are really specifying “qualities” of the feature (I want to be able to distribute this document very quickly (implying email) rather than via post).
Kim–I haven’t yet grasped why having everything be a quality of a feature rather than a new feature on its own is critical. But, I have a tremendous amount of respect for the Gilbs and so I’m trying to get there.
A couple of these suggestions are interesting–online collaboration sounds promising for example. I think I suggested revision tracking to them and the answer was that it could have been done with scissors and copies of a paper original, meaning that Word doing it so nicely only improves (dramatically, of course) the quality of that implementation
I’ve asked Tom and Kai to chime in here. Hopefully they do with and can help all of us. Thanks to all for discussing this.
To amplify some prior comments: If you’re going to define “spell check” as something that could have been done by manually checking every word against the dictionary, why not go all the way? There is absolutely nothing in Microsoft Word – or ANY software – that could not have been implemented by an army of N monks, N-1 of whom did nothing but remember a number from 0 to 255, with the last monk being the poor guy who had to manually implement the x86 instruction set.
I think the more interesting angle is the inverse (converse?): there are times when a change in number *becomes* a change in kind. When I can spell-check faster than you can type, I can give you instant spell-check. When I can index text faster than you can create it, I can give you full-text search. When I can resize photos faster than you can click, I can give you PhotoSynth. When I can transmit bytes faster than you can use them up with content, I can give you streaming audio, video, VoIP.
I have a submission for the “contest”: Animated text! (Format -> Font -> Text Effects).
Two caveats: If the “function” is “decorating text” and not “animating text”, this is just an “improvement”. I think the difference is in kind, and not in quality, though.
The feature is quite useless and stupid, as some of the commenters suggested a truly new feature would be.
To chime in to the general discussion: The fact that there are no new features is not criticism of Word (or any other program)! It is just to point out that the users of most software have stuff they wanna do better or faster, not gadgets they wanna play with.
To argue against myself: The reason it’s important to understand “Every feature is really an improvement” is because you can implement them as refactorings, and you can implement them along a spectrum as time allows. Come to think of it, that’s what nature does; it gets to the whole “half an eye” discussion (where half an eye really is useful, because a creature that can only distinguish light from dark still has an evolutionary advantage over one that can’t).
If continuous spell-check is only useful in its own right, then there’d be no point in implementing discontinuous spell-check. Then there’d be no point in determining “near match” algorithms, in which case there’d certainly be no reason to waste time discovering faster search algorithms. And if that’s true, then implementing continuous spell-check is a HUGE feature, requiring a ground-up rewrite, because for one thing, you’d have to invent some fast search algorithm…
If instead you view continuous spell-check as an improvement on “writing well-written documents”, you’ll implement what you can when you can, and you can keep moving toward the ever-distant horizon of “produce the perfect document automatically”. You’ll know how it fits into the larger goal; you won’t spend your time optimizing the squiggly-line wavelength when you could be working on live grammar check instead. If you only get it half-done, it’ll still be useful, and you’ll have an iterative test bed to discover emergent properties you didn’t know about (British English and American English need different dictionaries).
There seem to be two things in discussion here.
The first is the “challenge”. To which I offer that enough quantitative changes make a qualitative change. (walk -> bike -> car -> plane) (hand computation -> computer computation)
The other, which I find more interesting, is a key phrase that got lost in the way you stated it originally but you brought out a bit later – “Their point is that rather than thinking about what new functions to add, think about how well functions are executed.”
That is an interesting proposition. It probably combines with the first point, so that “Is there a way we can make some particular known function so much better that it changes the quality of life of the user?”
Alistair
One thing that I find usefull when taking digital notes is that I can insert lines in the text I ‘m writing.
You could argu this is possible with text by rewriting the text, and in that sense it is quality.
But when I do this when I take notes, I don’t have that time.
What about a password protected document?
Is a document in a vault the same as a password protected document?
Yves
How about a neural input plug-in that would allow a stroke patient, incapable of speaking aloud, to compose a document that he or she could share with the rest of the world? Is there any way those nutty monks could have pulled that off?
I suspect that Tom and Kai will say that password protection can be handled by paper in a safe. The neural plug-in seems like something new that is not just an improvement in the quality of a function.
So does that mean I won?
As I understood the challenge, that’s what you were looking for, wasn’t it? “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.”
AgileMan–
It would earn you unending respect! But I suspect your neural plug-in feature will be disqualified as not really being part of a word processor. Let’s see if Tom and Kai can comment. I’ve emailed them to remind them of our discussion here.
I actually wrote a long reply without a copy on the 23rd, but it seems to have disappeared into a black hole. Maybe it got automatically censored as it was too long? Not agile enough ?
Our main purposes of this ‘new function’ challenge are:
1. to get people to see the clear conceptual differences between
• functions (WHAT a system DOES)
• qualities (HOW WELL a function is done and experienced)
• design (HOW we DELIVERED THE QUALITY LEVEL to the function).
2. to move software developers away from their narrow fixation with functionality (including use cases, features) and towards the more interesting area of Quality Requirements. Functions are ‘fundamental’ of course. They determine the business our system is in. But Quality Attributes determine whether the system is satisfactory for its stakeholders, and whether it is competitive. We software developers are infamous for our frequent lack of even basic quality levels. I mean all types of “-ilities”, not just reliability. The basic reason, I believe, is that we think like coders, not like real software ENGINEERS.
3. to help developers recognize the essential distinction between functions and designs (see above simple definitions). The collection of so called Functional Requirements, seems to all too often contain ‘designs’ rather than function. A simple example is a ‘password’ as a required function, or ‘MS Windows’, instead of specifying the corresponding implied qualities of Security or Usability, as quality requirements; and then defending the engineering design options, in terms of their ability to deliver the required quality levels, at lowest costs and lowest uncertainty.
Great technical detail on all of this will be found as free downloads on http://www.gilb.com.
Try “Agile Now What” for starters,
http://www.gilb.com/tiki-download_file.php?fileId=30
and for the voracious appetite, try Evo – book length
http://www.gilb.com/tiki-download_file.php?fileId=27
We would hope to inspire some readers to use this information to transition themselves from coder to engineer. Lots of kids can code, but we seem to have too few real software engineers to satisfy the deeply felt need, by society, for appropriate qualities and costs of software systems.
An engineering approach is necessary, as it is elsewhere, for getting control of our trade. You can’t build skyscrapers with clever carpenters alone, or complex software with ‘softcrafters’ alone.
Best wishes to us all!
Tom (and Kai!)
Tom and I see our whole sw industry with methods, experts, books, professors, project managers etc. living in the mindset that we are delivering/developing new functions. And then there is some other stuff called non-functional.
In our view of the world our job is to take functions, and make them better, faster, more efficient, easier, more pleasant, secure, reliable, cheaper etc. Rarely if ever do we make new functions as seen from the users and stakeholders view.
Kim Gräsman and others, for me the distinction is interesting, I would say fundamental and crucial as to understand what we (developers) are doing, as to understand what our Stakeholders (inc. end users) expect from us.
These improvements don’t normally come by chance, you usually have to target them and find ways to get the improvements. For me it is ok to have a list of what the system I am developing must do, function requirements, 1 page will do, but what is essential is to understand how well those functions are done today, with the old manual systems I am replacing, or the old automated systems I am replacing.
I prefer to state that a task today takes 45 min. to learn how to do, and that with the new system (same function) the task is expected to take 1 min. to learn how to do. That is a good starter to get the creative juices going, and when that is delivered, the Stakeholders love it.
Real case example:
One of the projects I’m working on today as a coach, we have a large web portal with lots of products and services delivered by a set of service providers. We have written up all the improvements (qualities) they expect to the web portal in the improved version we are creating. One such quality is the time to find the correct product/service. Today it takes about 1-2 min. We gave the Scrum team that is doing the sw development the creative challenge to come up with some alternative ideas for how it can be brought down to about 15 sec. They came up with 12 such ideas, and we (management) have selected (with them) 2 of them that they are working on implementing right now. At the end of the sprints we will measure how much faster it is to find the products/services, and keep at it until we reach the goal.
So there is no focus on the function (finding the products/services), of cause it will be possible, all focus is on how well, in this case how fast/easy.
If you think this is interesting, or sound difficult, I like to tell you that we actually have several levels that determine that this is the most effective and valuable solutions we can do right now.
The 2 solutions are there to reduce the time to find the products/services. This reduction was the quality improvement that gave the most benefits to the Stakeholder Values that again gave the most benefits to the Business Values. So the impact of what the Scrum team develops have maximum positive chain reactions all the way up to the business values.
Sincerely
Kai Gilb
Good day Mike,
Thank you for opening my mind up to this concept. It solidifies some ideas that I have been carrying for some time into something more concrete and coachable. Of course, since it was initiated by Tom and Kai Gilb I thank them, as well.
The user story template of “As a I want to so that ” points towards the concept, in my opinion. By identifying the “so that” clause we are able to understand how it benefits (improves quality of function) to the user. Many people and teams have difficulty thinking in this manner and give up on the “so that” clause too quickly without understanding how that changes their implementation downstream.
While coaching I have focused on getting development team members and Product Owners to start discussing their user stories in a manner that discusses why the user story is a benefit over something done before. It was always a problem for me when they weren’t able to because I saw that they were then going to implement something without understanding how it brings more quality to the user’s experience. Thus, they will just develop a feature that meets the function explained and not drive out a solution to the current quality issue trying to be resolved.
If I always think about creating something “new” it causes me to think in terms of the function rather than the quality problem. Focusing on quality will allow us to see value in smaller chunks and therefore enable business to identify shorter cycles for delivery to their customers, I think?
Would like to hear more from Tom and Kai and I will be reading more on their site in the near future. Thanks again for the great discussion on a helpful concept.
[...] Mike Cohn brings a challenge to his readers that was initiated to him by Tom and Kai Gilb. See if you are able to answer the challenge in this article. [...]
The closest thing I came up with was the ability to change text formatting. I think it would be the most expensive and time-consuming to duplicate with pre-computing technology.
I can say it was the most exciting printing feature we had on our first computer. We made lots of signs with Print Shop, and spend lots of time playing with font choices and how they changed the tone of our signs.
And, while you could technically have a monk rewrite text in a different style (i.e., “font”), the return on investment would be extremely poor.
Thank you. This was a very interesting thought exercise.
My best answer to this question is “inserting a hyperlink”.
I realize that there are arguments against this. Of course, you can always write a url down on paper. You can also give directions to go look up the information in a library. You can also recopy all of the hyperlink’s information in your own paper.
But fundamentally, none of those are the same. If someone is looking at an electronic document (ie. doc, pdf) AND is connected to the internet (ie. everyone), then what you are essentially dong is providing them a unique hook into more information. The hook is instantaneous, requires no effort on their part and is optional. Pencil and paper can’t do that.
Hi Amber–
Channeling Tom and Kai, I will say that the user’s true goal is to “connect information” and that inserting a hyperlink is a mechanism of achieving that goal. The information could have been connected in the pre-computer days with a paper clip and a copy.
I tried a couple of suggestions along these lines with them such as that emailing a document to someone instantly is very different from printing it and mailing it. They weren’t buying that as an example of new functionality.
Ultimately I totally get where they’re coming from. It makes complete sense from the standpoint of most software coming from a “we’re already doing this, let’s do it better” approach. BUT I question the premise that “just because we could have think of a way to do something means that it was at all possible.”
Macros.
In general, tools are not about doing new things (“there is nothing new under the sun” – Ecclessiastes)
But about doing things better, faster. They enable US to do things We couldn’t do before. Or enabling more people to do things only a few could do.
We can see rocks with our eyes, but with telescopes WE can see planets.
When installment payments were ‘invented’ for large farm equipment, it meant more farmers could buy larger equipment (since they paid it over time rather than all at once), and produce more crops.
Anyhow, on the couldn’t do with paper list.
1) Macros:
2) Collaborate remotely (e.g., netmeeting, WebEx, EtherPad).
3) Hyperlinks
4) Zoom
5) Store 100,000 pages on a device the size of a pack of gum
Another quesiton to consider:
What can you “not” do (avoid doing), that you used to have to do with paper?