[ba-ohs-talk] The Potential of "Instant Outlining"
Rod Welch wrote: (01)
Your letter this evening has the following.... (02)
> http://radio.userland.com/
> --The basic client. $40.
> A quote from that page:
> "René de Vries: "This could do to sharing knowledge what
> email did to get people to communicate." (03)
....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. (04)
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. (05)
In this post, we'll look at:
* The Potential for Productivity
* The Potential for Knowledge Capture
* The Potential for Impementation Collaboration
* he Potential for Refactoring and Documentation Maintenance
* The Potential for Design/Decision Collaboration (06)
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. (07)
For outliners in general, that productivity comes in two ways:
1) The ability to find things.
2) The ability to move things. (08)
Everyone is now familiar with the relative ease with which you can a find
a file
in today's hierarchical directory structures. It didn't used to be that
way. There
used to be flat directory structures with hundreds or thousands of files
in them.
People came up with naming conventions to introduce a semblance of
hierarchy,
but no one really "got" that a true hierarchy would make things easier,
until and
unless they had used one. (09)
Textual documents are in the same situation today. To find a bit of text,
you
scroll down to get to it. You can search for it, if you remember the name, (010)
but that kind of capability existed in flat directories, too. It is useful
some of
the time. Not so useful at other times. It is just wicked fast and handy
to
drill down through an organized hierarchy to find things -- especially
when
you don't know in advance exactly what you're looking for. (011)
The other acceleration feature is moving things around. A knowledge worker (012)
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 (013)
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. (014)
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. (015)
Again, there is no good way to explain the feeling that comes with
tree-structured access to documents. It is just faster, easier, simpler. (016)
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. (017)
If nothing else, it would be fantastic for project todo lists. (018)
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.) (019)
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). (020)
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. (021)
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.) (022)
Now imagine a multiple-developer setting, and object-oriented, "design
by contract" programming. (023)
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, (024)
based on the standards in use by your team. (025)
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. (026)
That is certainly knowledge capture. (027)
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. (028)
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. (029)
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? (030)
And out of that colloboration process comes a record of design
decisions that may well prove useful for years. (031)
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. (032)
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. (033)
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. (034)
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!) (035)
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. (036)
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. (037)
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. (038)
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...) (039)
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. (040)