The Separation of Communication and Action:
I have separated
the communication of humans to the Adam, from the logic used by Adam to perform the action. Both systems are designed
independently because each system has unique design criteria.
The main design criteria for the communication system is, how do
humans instruct the Adam to do something with the least possible
effort. The main design criteria for the Action system is that it
be table driven.
Communication is always domain specific. The terms and words used to
instruct the Adam are specific to the task at hand. The primary
communication device is natural language, which permits common task to
be easily remembered, understood, and modified by humans. Since the
logic of the natural language interface is table driven the language is
not fixed and can handle any future adjustments.
The system for Actions is table driven, which permits adjustments by
context, by the environment and to the needs of each user. The zip
example (bottom of center column) could have a different language for
every users, yet work the same. Visa-versa the language could remain the
same, and the actions differ for every user.
The action resolvers, work just like the content resolvers; pulling
resources based upon context. A more useful example; my project to
fly to Mars in standard U.S. units, would be seen as Metric units in
"A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
"Any product that needs a manual to work is broken."
"Good design is obvious. Great design is transparent." Joe
"Perfection is achieved, not when there is nothing more to add, but
when there is nothing left to take away." Antoine de Saint-Exupéry
"The dumbest mistake is viewing design as something you do at the
end of the process to "tidy up" the mess, as opposed to understanding
it's a "day one" issue and part of everything." Tom Peters
"Remember, a dead fish can float down stream, but it takes a
live one to swim upstream." W.C. Fields
I am spending my time on design instead of
coding. One product I wrote in the past was Maverick Professional,
which took me over 25 years to write. It is a massive system to system
translation application with over one million lines of code. It worked
great, difficult to manage, limited in scope, and impossible to reuse.
Looking back, I would have had a far better product by simply changing
my approach, and accomplished the same task in 10 thousand lines of
I read that a designer of IBM's TSO operating system said "Yes! we
know there are many flaws in the system, but when you have a user base
it is impossible to make changes". This gave me my first
- how to make future improvements transparently?
The answer is to separate the system of communication from the
system of action.
The current technology of software development is completely
dependent on documentation. This brings me to my next design issue:
- how to remove the need for documentation
The answer is to reduce the effort by humans to a minimum for every
action. To build a system that already knows everything it can.
I need 100% confidence in what I say will be understood by
Adam ... the same way, forever.
A system for the management of verbs, nouns, adjectives,
prepositions, and other parts of speech in a way that their
meanings are understood in context as a free form natural
The language system breaks apart a sentence into the subjects, nouns,
verbs, adjectives, and propositions into a known structure that is
easily and confidently digested by the Adam.
The language is not fixed... for example: to zip a file: one
could use the terms "zip", "compress", "pack", or "save". What to zip
could be "what ever remains on the line", "qualified: input=...",
or resolved into a complete set of files "all files in the temp folder",
"files I changed since yesterday". Whatever the developer of the
zip utility wants can be fed to it in a consistent way. The conscious
brain [us] talk, the unconscious brain [Adam] acts.
Removing the need for Documentation:
Software development is currently in a world of details.
Remove the details and no documentation is needed.
Software development is different from any other
discipline in that is far more malleable, yet it is currently treated
like any other construction design job. The assumption is that one
product must be flexible for the user, so that it fits every imaginable
job. This flexibility is currently communicated as documentation.
The elimination of documentation requires a change in
many technologies. These changes can be summed up as "having a simpler
systems". Initially it will be impossible to achieve 100% compliance.
Just as there are still clocks in my house that require documentation to
set the time. I hope to build a system that promotes the simplification
of systems to a minimum or at least have a common knowledge base for the
elimination of documentation.
When I think of software development, I think of the
term "beating a dead horse". It's not going to get better no matter how
many times we do it. I hate the term "legacy", any software over a
day old is crap. I hate the term "version" as if there can never be
consistency. I hate the term "maintenance" as if software is never done.
And then we have the term "documentation", as if this will make
Table Driven Logic:
Everything in the system is managed by the system,
including the logic of the system itself. All information, resources,
language, and logic is maintained as multiple dimensional tables. The
system treats itself no different than the information it provides.
The primary design criteria for a table driven system is
that anything in the system can be modified at any time; dynamically,
statically, permanently, temporarily, in parallel, or sequentially.
Content on demand, this design, changes the whole nature of software
development. This reduces development time and the number lines of code
to their minimum. However; this does throw everything I know about
software development out the door.