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

"The most important things to say are those which often I did not think necessary for me to say -- because they were too obvious." -- André Gide

"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

"The 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

"We cannot change what we are not aware of, and once we are aware, we cannot help but change." -- Sheryl Sandberg

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 actually mean something.

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

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.

Conclusion:
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 to assume. 

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

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