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
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
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
difficult to say what is impossible, for the dream of yesterday is the hope
of today and the reality of tomorrow" -- Robert H. Goddard
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." --
NEVER -- Multiple Use Functions:
Generic functions should never occur. Coding functions for
multiple conditions has undesirable consequences:
- external placement of code
- unused code
- complicated logic
- complicated testing
- harder to debug
- reliability issues
- more permutations in logic
- assumptions on use
- complicated documentation
- complex testing of branching / context
- dependent code
- confidence levels drops
- 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
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
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 -- 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:
- Units of Measurement
- Lookup Values
- Resource Type
- Valid Ranges
- Field Length
- Definition of a Value
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.
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
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