Boeing
5301 Bolsa Ave.
Huntington Beach, CA 92647-2099



Date: Sat, 28 Feb 2004 09:53:46 -0800

03 00050 60 04022802




Mr. Jack Park
CALO Project
SRI International
333 Ravenswood Avenue
Menlo Park, CA 94025
..
Subject:   Experience Using SDS at Boeing

Dear Jack,

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.
  1. 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.
    ..
  2. 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.
    ..
  3. 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.
    ..
  4. 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.
  1. 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.
    ..
  2. 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.
    ..
  3. 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.
    ..
  4. 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.
    ..
  5. 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 of integration.
..
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.

Thanks,
..
Sincerely,



Garold L. Johnson
Modeling and Simulation