Dynamic Alternatives
http://www.dynalt.com/
City, St Zip
Date: Tue, 16 Jul 2002 11:39:46 -0700
Mr. Rod Welch
rowelch@attglobal.net
The Welch Company
440 Davis Court #1602
San Francisco, CA 94111 2496
..
Rod,
When we say that "books and documents don't work" this presumes that there are
purposes which are not well served by books.
..
So, let's distinguish some of the purposes of writing books about SDS.
- Provide credibility.
The fact that there are books published helps to convince people that the
idea is in the mainstream. It lends some inherent credibility.
..
- Provide a rationale for all of the features of SDS and relate them
to the delivered benefits, which is what people actually buy.
..
- Provide an experience of using the new concepts involved in SDS.
..
- The general reason for wanting a book is to acquire a body of
knowledge it exists, not to manage knowledge as it evolves.
..
Whether a book is an effective tool depends on what you are trying to
accomplish.
The nature of the book
..
If a book is to be written, I submit that it should be a management book
that sets out what constitutes "better management", and uses that to
motivate the sorts of solutions that SDS provides. For conventional print
media, a book on management should have more sales potential than one on a
specific piece of software.
..
A very good example is "Object-Oriented Software Construction" by
Bertrand Meyer. The book is an introduction to the Eiffel programming language,
but it is written as an analysis of the problem to be solved, the variety of
proposed solutions, and the rationale for developing the solution as it is
implemented in Eiffel. The result is immensely persuasive.
..
David Parnas wrote a paper entitled "A Rational Design Process: How and
Why to Fake It", that states that no system was ever designed top down, but
that a documentation trail can be created that is close to what would have been
generated if we had created the system top down, and that such a presentation
is what is needed to communicate the final result. This is what the Meyer book
does so well.
..
If you were to write a book on SDS, this is the approach I would recommend.
It would, of necessity, generate a total set of features of a solution - as
implemented in SDS.
..
Consider a book such as "Code Complete" by Steve McConnell. It uses numerous
features such as structured headings, sidebar icons with discussions and
references to related material. All of these features are intended to allow
the book to be used by people with varying technical skill levels or varying
interest in details. It does this reasonably well considering that it is
still a book. Judicious use of color, shading, boxes, and similar features
for expressing emphasis are also valuable.
..
Electronic Books
Anything that can be put on a web site can be put into an electronic book,
which allows a small web site to be delivered on a CD or as a downloadable
file.
..
This would be an approach to dealing with the interactivity and knowledge
space ideas used in SDS. Since the book wouldn't include the program, it
would be necessary to construct the subject and glossary index files so that
the entire result delivered the best possible simulation of using SDS (with
a database that can't be edited).
Consider if the electronic book contained all the SDS records needed during
the development of the book. Then the book would be an example of the use of
SDS in itself as well as the resulting work product.
..
But we already have...
There are indeed several documents on the web that explain a lot about what
SDS is and the philosophical concepts that give rise to some of its
features.
..
I can attest that these documents could be improved in that:
- After my initial reading, I still didn't understand what SDS actually
*does*. I have spent some time going through the documents trying to
extract requirements for SDS. It is not a trivial exercise, and I am far
from certain that I have it all yet.
..
- The narrative could be more tightly focused if it were based on a
theme. I have recommended the notion that the elements of "good
management" based on problems experienced trying to manage in the first
place and proposed solutions is one workable organization.
..
- The documents often seem to discuss problems without direct
solutions or ideas that aren't tied directly to problems.
..
In short, I am talking about a rewrite of the documents with an explicit
goal to create a knowledge space that both evolves what a good solution looks
like and presents the results of using such a system.
..
None of this should be tied to direct mechanisms used in SDS as that is
too low a level of detail. For example, discussing the operations that you
might want to perform on an action item provide a rationale for the entire
management of action items:
- Create a pending item with a time to become visible.
- Activate an item to put it on today's schedule.
..
- Generate follow up items.
- Issue documents with action items to others.
- Mark issued action items as requiring action by others with follow up
intervals.
- Tie action items and documents to relevant references to align with
objectives.
..
The result is that problems are demonstrated, currently proposed
solutions are introduced and shown to be defective, and a better solution is
developed based on the mechanics of knowledge and on the day-to-day use of the
system. If done well, the result is that the reader is left with the conviction
that the proposed solution is clearly the best possible, or maybe even the only
one possible.
..
I will have more to say about a possible structure as I make more
progress on extracting requirements from the documents.
..
In the meantime, I submit that the options are by no means mutually
exclusive. Restructuring the existing documents to deal more directly with the
motivations, features, and benefits of SDS would be necessary before writing a
book on SDS. The effort to do this with an HTML structure that simulated what
the user would see in an SDS system would improve the web presentation, and
this could be packaged for electronic delivery and / or as a CD.
Thanks,
..
Sincerely,
Garold (Gary) L. Johnson