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
..
Subject:   Book(s) on SDS

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.

  1. 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.
    ..

  2. Provide a rationale for all of the features of SDS and relate them to the delivered benefits, which is what people actually buy.
    ..
  3. Provide an experience of using the new concepts involved in SDS.
    ..
  4. 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:

  1. 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.
    ..
  2. 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.
    ..
  3. 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:
..
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