Sept 2015
Issue

Feb 2016
Issue
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 London.


"A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools."
Douglas Adams

"Any product that needs a manual to work is broken."
Elon Musk

"Good design is obvious. Great design is transparent." Joe Soprano

"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

Software Design:

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

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 design issue

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


The Language:

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

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 everything work...


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.

Author: Clif Collins
http://CollinsSoftware.com
Houston, Texas

January 6, 2016

email: c2@CollinsSoftware.com