February 2022

Probability of Logic:
Let us define "P" as the number of all possible solutions for a task. Out of these there are "R" number that are realistic.  Out of these there are "A" the number of actual solutions that have been implemented.

In our current software development methodologies, we usually only implement one solution which is hard coded to a single data structure. Therefore it becomes impossible to change either the solution or the data structure, which limits the scope, size, lifespan, and capabilities of our applications.


NEVER -- Use "Use Cases":
"Jane" is to change software development technology from the "hard coded single solution", to the implementation of all realistic solutions.  The system is to have the capability to handle all possible solutions, which can be added to over time. The selection of a solution can be explicit or context based.

For example, there are over forty common sorting algorithms. Each has specific characteristics that produce the same result.


NEVER -- Functions:
Functions are never required in programming. They are a human tool making logic easy to write. In the current technology, there is very little down side to using functions. However in "Jane" there is much more information available and functions will put a strain on the system. This strain is a reduction in execution speed, reduction in capabilities, and rigid logic that cannot be modified.

In Jane, the user will always see logic in the conventional functional form. However Jane generates the logic without using functions.  The reason is that Jane compiles at the instruction level not at the group of instructions level (i.e. as a function).


"In any moment of decision, the best thing you can do is the right thing. The worst thing you can do is nothing." -- Theodore Roosevelt

"Life always begins with one step outside of your comfort zone." -- Shannon L. Alder

"I like children - fried" -- W. C. Fields

"It is difficult to say what is impossible, for the dream of yesterday is the hope of today and the reality of tomorrow" -- Robert H. Goddard

"A good decision is based on knowledge and not on numbers" -- Plato

"The decision is your own voice, an opinion is the echo of someone else's voice." -- Amit Kalantri

"There is no point in using the word 'impossible' to describe something that has clearly happened." -- Douglas Adams,

 
NEVER -- Multiple Use Functions:
Generic functions should never occur. Coding functions for multiple conditions has undesirable consequences:
  1. external placement of code
  2. unused code
  3. complicated logic
  4. unchangeable
  5. complicated testing
  6. harder to debug
  7. reliability issues
  8. more permutations in logic
  9. unreadable
  10. assumptions on use
  11. complicated documentation
  12. complex testing of branching / context
  13. dependent code
  14. confidence levels drops
  15. Hard to develop and maintain

In conventional programming the above is true. You should never have conditional logic in a function (i.e. multiple use functions). By coding single use functions you generate a little more code, but you also eliminate all the above consequences.

In Jane all logic is table driven and no functions are ever generated. Externally to the user, groups of statements will look like functions, but internally to Jane they are simply an ordered set to instructions with all required logic and information managed by Jane.


NEVER -- Dependent Coding
The current software development technology is designed and built on dependent logic design. The best situation is having no dependencies whereby all code is under your control. This means that each unit can be tested and modified independently. 

It took me two years to write my first 100% independent logic unit. I had, at the time, 38 years of software development experience. It was extremely difficult to shed past bad habits. Even now, with 8 years of experience writing  independent code, it does not come naturally.

Take for instance: "character design",  where "ASCII" separated the characters by case. This design dependency alone has wrecked havoc on application logic for the past 58 years. 

Dependencies are not just the use of an API or a subsystem, it is anything that influences how we design our application.


NEVER -- Logic Permutations:
The goal is to separate code into individual logic units. This is to reduce the complexity of the code and permits testing on an individual basis. If a piece of logic breaks it will only affect itself.

All permutations of logic must be individually verified. As the number of permutations in logic grows so does the probability of failure.  With just five logic conditions there are 120 permutations that need to be tested. We generally test one and assume the rest will follow suit, and they never do.

 
NEVER -- Hard Code Information
Intermixing logic and information is the worst thing you can do. It is the root cause of all software failures.  The hard coding of information in the source code of an application hides information from all others. This information can be either explicit, derived, or missing.

Some times required information is not explicit or derived but in the programmers mind. Here  is a list of Information that is never specified:

  1. Units of Measurement
  2. Lookup Values
  3. Resource Type
  4. Valid Ranges
  5. Field Length
  6. Definition of a Value
  7. ...

The list is as long as there are number of types of information.  Information can be missing for any number of reasons, from never given, to never knowing, to having no place to put it.


Dependencies:
The ultimate goal for software development technology is to eliminate all points of failure. The only way to do this is to have the ability to know they exist. The only way to have 100% confidence in any system is to have complete control of the design and implementation process.

We program reality. Unfortunately reality is different for everyone and for every situation. We should not program one reality, but rather we should give each person the reality they needed to do their job.  I call, having dependencies in software a "Wine Glass Technology".


Conclusion:
The cost that occurs due to our software technology is horrible. Trust in the computer is eroding. The more software that we build it only makes things worst. We must change what we are doing to move forward.

The only way to move forward is to learn from our mistakes and start over.

The horse over walking, the car over the horse, trains over the car, planes over the train, and so on.  You have to realize that one technology is of no benefit to the next technology. In software we are still walking. Lets get to the next level.


by: Clif Collins