Re: [ba-ohs-talk] Case In Point
James Michael DuPont wrote: (01)
> What has to be written :
>
> what function, what modules, what interfaces, what
> classes? What applications, what services?
>
> This needs to be tacked down, you need a design to get
> contributions, a map so people know where to put thier
> efforts. (02)
Yup. But if the complexity were of such managable proportions
that we could wrap our heads around it, it would have been
done. I took two strong stabs at, first, the requirements, and
then the design. (03)
Lee took an even stronger at the design for the underlying
architecture needed to build such a thing on top of it, but
the design for that thing is still not fully specified. (04)
This is all part and parcel of the issue. It is in the nature of the
"wicked problems" that Horst advanced and Conklin so
eloquently described. (05)
To this, we add the chicken and egg dilemma that we do not
have the collaboration tools necessary to do collaborate
remotely on the design of a collaboration system. (06)
Just after the 2000 Colloquium, one of the members of this
list proposed that those of us who were physically co-located
should get together and make a first cut at such a thing, so we
could then begin to use it and improve it. (07)
It made sense, and we spent a lot of time in an attempt to do
just that. The work product you've seen, in form of requirements,
proposals, and preliminary designs, came out of those efforts. (08)
What will it take to finalize the specification? Deep thought, trial
and error, and prototypes. What will it take to create the
prototypes we can reason with and reason about? Specifications.
Do you detect the circularity. (09)
I advanced one proposal a while back. Eugene has been working
on purplizing our email archives, Lee has worked on an engine,
Jack wrote some things, Paul has something, Mike has something.
Others have advanced suggestions that I'm too bandwidth-limited
to recall. (010)
Lots of folks have pieces of the puzzle. And they're all their in the
archives. In fact, there are dozens of options for most every facet
of the puzzle, and hundreds of combinations that might work together. (011)
How do we put the best of the ideas together? How do we take
baby steps that lead towards bigger steps, and eventually giant
leaps? (012)
I think purpilizing the archive, making it accessible, and beginning
to add categories to it helps to begin making a KB out of it. So
I suspect that Eugene has been taking the appropriate kinds of
steps all along. (It would be most enlightening, I think, to start
putting an IBIS structure on top of that archive, as a way to relate
the pieces in it.) (013)
After my conversations with Lee, I think a Nodal kind of system
has a strong chance of being the underlying data engine for that
step, or at least the next one. But I never got that sense from our
electronic interchanges -- a sign that head-to-head communication
is still the best option at our disposal. (014)
Bottom line: How do you specify what you do not yet understand?
The answer is by incremental design. Build it. Learn from it. Modify
it. Eventaully figure out that it is a dead end. Throw it away and
start over, using what you learned previously. It's easier this time,
but you still learn from it, and continue modifying it. Repeat until
you've
got it. THEN you can write up a specification for it, because now you
understand it. (015)
Finally, I would ask that we try to put the shoe on the other foot
for a while. (016)
How about if those of us with code that isn't ready to share, or which
can't be contributed for licensing reasons, write up *their*
specifications.
Then we can at least think about the approach they recommend. (017)
I did that with the code I built. I wrote up a design document that
tracked my thinking as I was writing. That's my specification, such
as it is. Since the complexity eventaully overwhelmed me, it never
got cleaned up and simplified down to the final, working version. (018)
Lee has written up a generic description of Nodal, too. The only
part that remains is writing up a spec that translates requirements
into a design that uses his engine, or one like it with the
modifications
Eugene suggested. (I don't recall that a conclusion was ever reached
in that discussion, BTW. Was it?) (019)
Basically, after a lot of hours in weekly meetings, a lot of thinking
with respect to requirements, and even an attempt at generating
some useful code, I think I've contributed what I reasonably can
as a solo developer. It's there on my site. (020)
Improvements are welcome. Alternate specifications are welcome.
Ideas, code, and suggestions are welcome. (021)
Have at it! (022)