Date: Fri, 19 Apr 2002 15:26:41 -0700
| From: | Eric Armstrong |
|
eric.armstrong@sun.com Reply-To: ba-ohs-talk@bootstrap.org |
| To: | ba-ohs-talk@bootstrap.org, hm |
|
eric@treelight.com |
| Subject: | Potential of "Instant Outlining" |
Rod Welch wrote:
--The basic client. $40.
A quote from that page:
..
....there is a report that "work group productivity soared." Is that
based on a
general feeling, or is there a calculation of ROI?
....
Based on your experience developing an outline program, what is it
about this report today that justifies the proposition that it aids
"knowledge"?
..
Fair questions, Rod. I guess I expected everyone to have the same Aha! reaction
that I did. But you're right, it needs further explanation.
..
This post is an eassy. It looks at one scenario, off the top of my head, but I
suspect that it is fairly representative of the kind of productivity boost they
experienced.
In this post, we'll look at:
..
The Potential for Productivity
I'm sure there was no calculation of ROI, anymore than the first spreadsheet users did an ROI study to justify their claim to increased productivity.
The fact is that when you automate tasks that used to take a lot of work,
productivity goes up.
..
For outliners in general, that productivity comes in two ways:
The other acceleration feature is moving things around. A knowledge worker
organizes and reorganizes.
..
When working on my book, rearranging takes time. The other day I moved a
section to a different chapter. First I rearranged the TOC, then I went to the
relevant chapter, scrolled to the start of the section, clicked the mouse,
scrolled to the end of the section, cut the text, made sure not to save the
file so the information wouldn't be lost if the computer went down, opened the
new file, scrolled to the new location, inserted the text, saved the file, and
then went back to the original file and saved that. Whew.
..
With outline-based processing, the process is: 1. Rearrange the TOC. 2. Stop --
you're done. The kind of capability lets you reorganize at close to the speed
of thought. Fast rearranging means you reorganize whenever a better arrangement
occurs to your. It makes a big difference in being able to keep track of
things, and find them later.
Again, there is no good way to explain the feeling that comes with
tree-structured access to documents. It is just faster, easier, simpler.
..
The Potential for Knowledge Capture
The ability to do move and find things is a big productivity enhancer by itself, but the Radio Userland app takes it into another dimension by making it possible to share information with others.
If nothing else, it would be fantastic for project todo lists.
..
My first outliner prototype used the hierarchical directory structure, empty
files, and a few command scripts. The name of the file was a note to myself
about something I needed to do. (File contents were always empty, but they
could have held some data, I suppose.)
Filename prefixes reflected the status of the item. An "X_" prefix
indicated that the item was done. "O_" indicated it was open (todo).
"Z_" indicated it was pending (sleeping, waiting on someone else).
..
The directory structure matched the modules I was working on. While working on
one module, I often thought of things I needed to do in other modules. I would
record an entry under the appropriate heading, and quickly get back to my
original task. Because it was fast, it was minimally disruptive. But when I got
to that other module, I had list of the ideas that had originated while working
on every other module in the system. It was enormously helpful in making sure I
didn't overlook anything.
..
That worked for a single developer, and it was incredibly useful. It
was so useful that I wrote another version, this time in Basic, that
added automatic numbering and atomicity. It was a fun project that
was the basis for the much improved version my two partners wrote
later on, in C. (Unwisely, I was not involved in the coding, and missed
a great opportunity to learn a hell of a lot from those guys.)
Now imagine a multiple-developer setting, and object-oriented, "design
by contract" programming.
..
You're working on a module, and you expect that a routine in another
module will return a zero value in the event of an error, rather than a
null. You go to your outline, and insert either a question or a statement,
based on the standards in use by your team.
The developer of that module now has an implementation checklist to
follow. More importantly, that item of information is captured as part
of the module's contract, where it can be referenced by others. It takes
the concept of "javadoc" (api comments embedded in Java code) to a
whole new level -- because it documents not only the things the developer
thought to say, but automaticallly captures the answer to every question
that others asked about it, as well.
..
That is certainly knowledge capture.
..
The Potential for Implementation Collaboration
Such a system is a collaboration tool, as well. When I say that I
expect the routine to return zero, and someone else expects it to
return null, the point of contention is not only made visible, but the
competing requests stay adjacent to one another.
..
In an email system, by contrast, adjaceny only happens when the
concerns arise synchronously. If I send a message about my requirement,
and you happen to be aware of your requirement *at the same time*,
then our messages will be part of the same thread. But if you or I
encounter our concerns at some future date, there will be no adjacency.
Further, when I say "Hey, I need this method to return 0", and the
original developers have left the building, there is no one say "here's
why it returns null". Can we afford to change it? Who knows? What will
break if we do? That requires time for analysis. Why did we do it that
way, anyway? Who knows?
..
And out of that colloboration process comes a record of design
decisions that may well prove useful for years.
..
The Potential for Refactoring and Documentation Maintenance
The caveat I would take note of is that in the scenario above, the
design is already settled. There are modules, so a structure is well-
defined for (in effect) categorizing notes with respect to the modules
they affect.
..
However, once created, such a system would be a tremendous help
when refactoring, -- both due to the ease of reassigning responsibilities
by reorganizing things in the outline, and the ability capture a many
additional details that frequently would not have been documented
by the original author(s) of the system.
Similarly, questions about old commentary can expose the fact that it is out of date or inaccurate, and lead to revision -- or least to a notation of the inaccuracy.
..
The Potential for Design/Decision Collaboration
The only remaining question is how well such a system works for
an *initial* design. In such a setting, module definitions and
responsibilities are extremely maleable. You can't rearrange
everyone to reflect a new design without impacting everyone's
ability to make sense of the system. (Suppose someone came in
and reorganized your message folders or your directory structure,
for example. Gad!)
..
There may be ways around that problem. Maybe I transclude a whole
module at one point in my proposed design, and break another module
into parts, transcluding pieces of it into a new framework. The proposal
I put forth for a new design may therefore a document that reuses
existing pieces in a new configuration.
That's problematic too, in some ways. If I reusue module A, and
then that module is effectively retargeted at a later date, the
transcluded module isn't going to make much sense in my design
context.
..
For it to keep making sense, I would have to transclude
the original version. That leads to the question of figuring out
which updates to the original version are incremental, and which
effectively create a fork by defining new semantics for that
module.
I suspect that the solutions to those issues will emerge in the form
of collaboration methodologies (the human system, in Doug's terms).
But I think that "instant outlining" (I still love that name) can be a
big part of the solution. (Add Traction-style categories and
new-message detection and man-oh-man, you are SO there...)
..
Summary
Instant outlining has a lot to offer for collaboration, knowledge
capture, and productivity. With the addition of some missing
features (categories and new-message notification), it could be
a whopping great killer.
..
Sincerely,
Eric Armstrong
eric.armstrong@eng.sun.com
Armstrong Consulting