Reflection on Inspection:
Air Canada Flight 143 runs out of fuel (1983). The fuel needed for the
flight was calculated by hand by the fuel truck driver. He used pounds
instead of kilograms, so 1/2 the fuel was loaded, hence the plane crash
landed. On landing the airplane's front nose landing gear collapsed,
skidded to a stop and the insulation started to burn.
If I reflect on this, first the airplane should never have started it's
engines. I (airplane) am going to fly 1500 kilometers, I don't have enough
fuel, maybe I should tell someone. Second, maybe the airplane could give the
truck what it needs. Third maybe insulation should never burn, to
eliminating harmful smoke and fire.
I spend my days writing code. I find my time is spent less and less on
typing, and more on reflecting on the software development technology as a
whole. Actually I think more on reality, and far less on what to type.
API, The Land of Assumptions
I personally never use any API. I find that it takes far less time to
write what I need than to use someone else's logic. Someone else's logic
forces me down a path of too many unknowns.
I believe that the curse of our software development technology is that
we only implement single solutions. I hear a lot of talk about "Use
Cases" and "Project Specification Documents". So we write applications and
try to make them either overly generic or too specific. This is the wrong
approach. I rather work from a wish list. Tell me what you want. So
instead of me writing a single application that assumes what capabilities
are needed based on my assumptions, I write an application with no
assumptions at all.
In Jane there are no fixed applications, rather everything, even Jane
herself is generated from a user request. This includes compilers, Operating
Systems, Banking Systems, editors, print utilities, databases, browsers,
.... Every piece of every application is selectable, testable, changeable,
and extendable. Use Cases to Jane are simply qualified applications. This
includes the terminology and display characteristics of all the forms and
user communication supplied by the system. Jane is a single infinitely large
"The most important things to say are those which often I did not
think necessary for me to say -- because they were too obvious." --
"About the only thing you should ever assume is responsibility."
-- J. S. Felts
"What we assume will be temporary often becomes permanent; what we
assume is permanent often proves temporary." -- Getchen Rubin
"Remember, we see the world not as it is but as we are. Most of us see
through the eyes of our fears and our limiting beliefs and our false
assumptions." -- Robin S. Sharma
I assume all spiders are dangerous, I am afraid -- Clif
surest way of concealing from others the boundaries of one's own knowledge
is not to overstep them." -- Giacomo Leopardi
"Be the change
that you wish to see in the world." -- Mahatma Gandhi
change what we are not aware of, and once we are aware, we cannot help but
change." -- Sheryl Sandberg
Assumptions in our Software Technology:
All software that as ever been development has been to one person's
assumptions on its purpose. These assumptions on purpose must therefore
be interpreted by programmers that use software developed by a group
of individuals with diverse assumptions, skill level, and resources.
This can be seen in everything. I worked for the power company in
Houston using COBOL. I needed, and could easily write a Julian
Date (day of year) function. The company's source code library had
literally hundreds of Julian Date functions. Wanting to conform, I spent
five days reviewing all of the functions to find one that I could
understand and use. Exhausted, I finally gave up and wrote my own.
Using Python, I need a know when the user closed the form. I had to
try all the different versions of Python documentation of resolve the
issue. Four hours wasted.
Every line of code I write there are assumptions on my part on its
use, purposed, capabilities, reliability, and its correctness. I
assume in assembler that all similar opcodes functions similarly.
I of course would be wrong. I assume when I use a Microsoft library to
write a buffer that it does just that. I would be wrong, it
automatically added a carriage return and line feed characters. I assume
when I add two integers that it is always going to work. I assume that I
can compare two text characters. I assume when I start a project that
the specification are accurate, and that they will not change. I cannot
think of anything in software development that is not an assumption.
There are many reasons for the assumptions, but they all stem from
the software development technology itself. The very first thing we
learn in programming is that we must make an assumption on the size of
an integer. This assumption alone dictates how an application is
written. We make an assumption that the names that we make up to
What's In a Name:
Actually very little, only that which has been declared. In programming
we declared names for everything the programmer wishes to reference. The
names themselves mean nothing. Knowledge only occurs when the meaning of
a name is known and only when its context is also known. We can assume
the meaning of a name, that is the best we can do when dealing with
programming languages, and in dealing with the work products of others,
and even our own work (we forget).
Names are not organization, nor do they have any explicit knowledge
attached to them. We should not be using names to program with. We
should be programming with the human vocabulary, and all the rules of
their common use. If we do this in programming we would then have
If I say "A equals 4" "A" means
nothing to me. However if I say "A is 4 in
cat years" it does have meaning. We should talk to "Jane"
(the computer) as if we were talking to a human. In a way we are talking
to a human, all those that need to understand. You say
"My cat is 4" I then ask,
"is that cat years?". If the computer knew, it could
answer correctly, NEVER ASSUME ANYTHING. Yet I assume "4" is
years, it could be anything when taken out of context:
my cat is 4
[years old] "our assumption"
my cat is 4 [cat years old]
my cat is 4 [days/weeks/months old]
my cat is 4 [inches/cm tall / long]
my cat is 4 [pounds / kilos / stones ]
my cat is 4 [th on the list]
my cat is 4 [her name is 4]
We have to consider what the meaning of "4"
is, in relation to a "cat".
Without the reference to a cat, then I have to consider all the meaning
of "4", which has millions of possibilities. We really need to
"know" the specifics when programming, yet we never do.
Removing The Assumptions:
The problem with assumptions is that we (programmers) do not know is
they are correct. We use our experience to make a judgment on what will
happen when each statement executes. I would say it is a 50
percent chance that we will be right, and 50% that we will be wrong. The
thing is, we never really know if we chose correctly. In the same
situation, with the same exact statement the results can change.
The language that we use defines the ability to communicate. In
software development we have no language to communicate.
Jane is to have a language with four
levels in which to communicate:
Level 1: Natural Language to communicate from the humans
to the computer, of what actions we wish the computer to perform
Level 2: A common language scripting language that is
understood by both the human and the computer. This language contains
all the details of level 1 plus all the qualifiers that the human knows
and wants the computer to explicitly know without assumptions
Level 3: A logic Language. The logic requests taken from level
2 scripts and put into action.
Level 4: A hardware implementation logic language. This
language isolates hardware dependencies from Level 3 scripts.
These four levels are contained in one compiler, with syntax specific
to the communication requirements of the user.
Assumptions simply means we do not know. When we write code we know
everything we need for about five minutes. This knowledge is only
known to the person typing in the code. After that, since code is
unreadable, all the knowledge required disappears and so we are forced
We must have confidence in what we say will be understood by the
computer. However it is impossible when our technology reduces
everything to the bare minimum vocabulary. We are forced to use a small
vocabulary of ten words and twenty symbols in which to convey
An assumption means that you do not know. If you do not know then you
can never have any confidence in the results. When we make changes, or
use someone else's API, that is when it gets really bad. Then the whole
work process is 50% assumptions, and therefore it, by the nature of
things, has flaws.
When changes to code is performed we have to assume the correctness
of each statement along with its purpose. When reading the code we
have to assume the original programmer intentions. Maybe what was typed
is not correct. Errors in typing is possible, however there is no
possibility of read checking any code. We are forced to fall back
on stress testing the code, which is based on our assumptions, along
with the assumptions of our assumptions.
by: Clif Collins