April 2017
Issue
June 2017
Issue
Purpose

By changing your style of programming to remove internal dependencies will reduce your total project effort by 50%, produce unbreakable code, and have code that can be changed at any time.  This is simply what software development is.

I build yoyo's does not mean I'm an expert yoyo'er. I have spent 3 years trying to learn how to remove internal decencies, it is not as easy as it sounds. You will want to fall back on what you've done in the past. I did this on 1 line of code that took me 3 weeks to resolve.


A Linker

In my last newsletter, I talked about the JavaScript compiler as a part of "Jane". The compiler will run in emulation mode, and produce executable code. To produce an executable, as a part of the software, a linker was required.  It took me two days, just to read an object library to extract object code to be placed into the resultant executable.  This is the same amount of time it took me 30 years ago to do the same thing.

The point is, our basic static structures separated from logic is no better, and might even be worse, today because of the number of versions, variations, and vendors of the same structure. If I were to do all the different formats and logic for all these different structures, it might take six months of work.

One of "Jane's" primary goals is to manage all information. So access to known information structures will take seconds not man months of work, with far greater reliability.


"The Holy Grail"

Mr. Crockford, is right for Software Engineering, as a science it would be great. In eighty years we have yet to produce one line that meets the code reuse criteria. 

I directed my efforts to software development, which is the practical application of creating software. So if I know that in 80 years and billions of man-years of effort has yet produce one line of re-usable code, maybe something is wrong. 

Code reuse It like searching for and wasting time on anti-gravity, when a more practical approach, airplanes, might hold a better solution. We can assume that anti-gravity and code reuse could exist. I do not waste my time on either one.


Quotes:

"Code reuse is the Holy Grail of Software Engineering." -- Douglas Crockford

"There are no true synonyms" -- my fifth grade teacher

"Behind every great man is a woman rolling her eyes." -- Jim Carrey

"Progress might have been alright once, but it has gone on too long." -- Ogden Nash

"The best time to plant a tree was 20 years ago. The second best time is now." -- Chinese Proverb

Removing Internal Dependencies:

The two reasons for software failures are internal and external dependencies. An external dependency is software that you did not write, software that you have no control over. An Internal dependency is software you did write and used it for more than one purpose. Getting rid of external dependencies is easy, re-write everything yourself. Getting rid of internal dependencies is a little more difficult.

The reason for removing external dependencies should be obvious; any external change will break your system. The reason to remove internal dependencies, may not be so obvious, it will improve your software in four way: First is it makes software code unbreakable. Second it will reduce the time to develop software. Third it will speed up the execution of the program. Fourth it will make software changeable.

My initial thinking was to reduce the number of internal dependencies on any piece of code to a manageable number of permutations. Three uses of a piece of code has six permutation. So if each piece takes 1 hour to implement, this is 6 hours. It seemed a reasonable assumption. This assumption is wrong, we have based all of our software development on this assumption for the last 80 years.  We have been spending more time designing software for reuse without any real or practical benefits.

I now promote zero reuse of code. Whether it's one line or a million lines, code should only be used for one purpose. This means building a system that only has a linear forward progressive logic.

Instead of trying to collapse code to reduce size, we actually expand code to reduce size.  We also expand code to drastically reduce development time by as much as 80%.

As an Example:

A and B both call C, this requires A and B to agree on a calling convention and balance the logic to suit both. This can take man years to develop properly. Future changes have risk, and there is no accountability.

A calls C1,  B calls C2, now A and C1 are independent from B and C2.  This I can do in under 30 seconds. Accountability is 100%. The size and complexity of C1 and C2 are reduced. I can change C1 and C2 with 100% confidence.

In forty years of development, I have never seen a function called from 2 parts of any system that had identical purposes. The few cases that you might think are identical, is not worth the 30 seconds it takes to isolate your code.

I can place C1 and C2 right next to where they are being called. This gives me the ability to visualize and alter the logic at will.


Words that make no since:

Object * Abstract * Virtual * Polymorphism * Inheritance * Cloud * Big Data * Instance * Encapsulation * Refractor * Namespace

These terms were used to describe application specific logic. The terms are too vague and do not describe logic, rather hide 2 or 3 lines of coded logic. I would prefer words like: Place-holder instead of abstract, Replaceable instead of Virtual, Fix instead of Refractor, and so on...

 

Intelligent Data Structures

I can probably count on my fingers and toes all the data structures that I need access to.

  • Font Files
  • Images
  • Videos
  • Vector Graphics
  • Object Code
  • Database Tables
Maybe 10 or 20 more. "Jane" is to build and manage data structures as an integral part of the system.  So the code to create, manage and access them is immediate. No more days or weeks of coding just to access something already known.
 


Compiler Update:

The JavaScript compiler now has access to object libraries, so I can write C++ system routines to finish the compiled version of the JavaScript compiler.

This means the compiler will run in all the current browsers to produce a 64 bit windows and ARM executables.

I have also extended JavaScript to know the difference between integer, whole, and real numbers.


Diagramming Source Code

Designing and writing software is an illusion of logic.  As a part of designing Jane I diagrammed source code, how was it written, what percentage does what part, and what percentage is actually logic. 

It turns out that logic only makes up 3% of the code. The remaining 97% is gaining access to information so the logic can be applied, and then doing something with the production of the logic. For example "draw a character on the screen" the logic is 60 lines, the lines of code to get to the logic is 2,000 lines. 

The production of logic is done in a very small time frame. Writing the 60 lines of logic of the draw character example might take 30 minutes; In this 30 minutes I have complete understanding of the system, where the data came from, where its going, what I should do, and how to best test the logic that I am now implementing. It is also true that I am the only person that knows this information. Once I am finished, I no longer know this information as well as I did during the 30 minutes of writing the code. Over time I may not even remember that I even wrote the code.

With this information, I designed Jane to manage the data structures, the logic, testing and every piece of knowledge when the logic was written.

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

email: c1@CollinsSoftware.com