5301 Bolsa Ave.
Huntington Beach, CA 92647-2099
Date: Sat, 28 Feb 2004 09:53:46 -0800
03 00050 60 04022802
Mr. Jack Park
333 Ravenswood Avenue
Menlo Park, CA 94025
Experience Using SDS at Boeing
Sorry for the misunderstanding.
Republishing my non-sensitive records is on my "real soon now" list (has
been for a while).
As I get time, I will try to relay my experiences with SDS.
As a program, it suffers from its date of origin - it is based on a DOS
version of an early Unix line editor with the addition of mouse support.
As Rod is very good at following a procedure once he works it out, there are
lots of places where it works for him all the time, but some variations can
lead to problems. He has been correcting those as I trip over them, so the
program is far better than it was when I started working with it.
In addition to using SDS and suggesting improvements, I have been looking at
what is required to get it into a modern form. It needs to be based on an
editor, and decent text editors with source code are not plentiful. I have one
candidate in Delphi that I intend to research.
I am constantly working to identify and separate several aspects of SDS that
are highly intertwingled.
Work practices. As with any program, SDS is designed to support the
user in carrying out operations on data. Those operations are based on
work practices, and if you don't work that way the lack of fit is a
problem. SDS has a pattern of working that it is designed to support,
and to use it effectively, it is necessary to adopt at least some of
those work practices.
Management practices. SDS is based on set of management practices.
Getting an organization to adopt any set of reasonable practices turns
out to be a real challenge. SDS supports meetings as they are supposed
to be run - agenda, old business and actions, new business, notes, and
repeat. Every management book, course, or tape says that meetings need
to be run in this way, but very few meetings actually are. SDS is
designed to start with the record from the prior meeting as a base.
All headings are automatically linked back to the prior record. For
about 6 months, no two meetings that I covered dealt with the same
topics, so I didn't even recognize the feature.
Philosophy. SDS originated as a tool to help Rod do things that he
wanted help with. Philosophy came later and helped to develop the
program further. That interplay is standard fare for anyone who pays
attention to the why's while evolving software, but Rod has taken it
to new levels. Since SDS developed through use rather than just
theory, it is quire good at what it does, but idiosyncratic because it
works exactly the way Rod works.
Program implementation. I continue to work to separate those
aspects of SDS that are essential (without them there is no SDS),
which are simply artifacts of the development process, and which are
related to the work practices or management practices. This is not at
all easy. Rod and I continue to bat things around, and I *think* I
have a handle on much of the distinctions.
At this point, I can use most of the facilities of the program, though nowhere
as well as Rod. It has become a powerful tool for me, and losing access to it
at work has adversely impacted my productivity big time.
Several things become evident after working with SDS for some time.
SDS integrates a number of facilities - editor, subjects (topics),
contacts, todo list (action items), schedule, diary, contacts, notes,
files. I doubt that there is any single one of these (with the
possible exception of Subjects) that some other tool doesn't do
better. However, when all of these are integrated as they are in SDS,
links can connect any record or file to any other, schedules and plans
become records of work performed, searches can locate information
based on any of the available hooks, the resulting synergy puts a lot
of power in the hands of the user. This is one of the issues we face
in trying to rewrite SDS, is the integration of the various tools.
Chronology is a very powerful tool for organizing and retrieving a
record of work performed, even when time isn't particularly important
for the specific work itself. The idea that work can be scheduled and
that planning record be used as the basis for actually doing the work
with rapid access to the history of the work on the task results in a
whole new way of working. I can't say that it is necessarily the best
in all cases, but it is powerful.
Hyperlinks are vital. Without hyperlinks, I am not certain exactly
what you have, but I am pretty sure that it isn't knowledge. This is
one of the major drawbacks of the Office tools. Many have asked about
creating SDS in Office, but without the ability to create hyperlinks
between arbitrary points in separate documents and branch to them,
there is simply no place to start. Perhaps the job could possibly be
done by somebody knowledgeable about Open Office at the source code
level, but I doubt that I could master it to the point of making the
needed modifications in any reasonable time frame.
Since SDS can link to all of its own files and there is no way that
I have found to link to most foreign files (Office, PDF, etc.) we
encounter what we refer to at the "two worlds" problem - anything that
needs to be analyzed in detail using the tools in SDS has to be
converted to text and imported into the SDS system. This is actually a
"multiple worlds" problem that all software experiences to some degree
-- how do I deal with written notes, voice recordings, video,
graphics, files of all types, etc. We have worked to reduce the
problem, but it isn't at all easy. Exporting a Word document as text
is often a real mess. It can't handle tables properly, for example,
and often what it does with list is less than pretty. PDF is even
worse, though PDF Converter from ScanSoft does an excellent job of
converting PDF into Word at a reasonable price ($50). I have written
some Perl scripts to help with some of the conversion issues, but
there is much more to be done.
Using text files as the basis for records, and a directory
structure to organize them in a chronology is a powerful idea.
Blosxom uses this approach. Since many operations within SDS can be
characterized as taking one or more files in and creating one or more
additional files, some of its operations can potentially be handled by
external programs, providing a way to improve the program and move
toward a new version without having to do it all at once, I have plans
as to how to proceed, but little time. The downside to using text
files is that the formats need to be very flexible and yet can be a
source of consternation when a record ends up different in some
non-obvious way and things break. At the other extreme is something
like XML which requires a lot more resources to manage. I am working
on intermediate solutions oriented primarily around structured text as
used in Wiki's
I won't go so far as to say that no other program can do knowledge management,
but I will say that, for all its annoyances and irritations, SDS has provided
me with a powerful tool that allows me to do some things that I have been
unable to accomplish before. I use other tools heavily, and am building tools
to migrate between them and SDS. I would love to be able to do a smoother job
Above all else, I believe that SDS has a critical mass of features that make it
a valuable test bed for ideas and approaches to improving personal
effectiveness, and that when it can be updated from its limiting DOS heritage,
it could provide some extremely valuable insights and an experimental platform
for augmenting (not replacing) human intelligence.