The Grand Unified Theory of Software ... or at least a NATURAL theory of software

The big idea

Define code as structures a la mechanical primitives

Create rules to represent applications as aggregates of such primitives

model notions of stability, brittleness, etc as functions of the aggregate structure

Model things that cause code to change structure or behavior as forces that act on it and derive ways of predicting their impact

Model the subjective nature of such a theory by including the human observer within it

Model the "Turtles all the way down" nature of software

Try to come up with "natural" formulas, ie those that do not need empirical constants to determine their value

origins and seeds

Alan Kays talk that showed the Windows code as being larger than the Empire St. Building when printed out on A4 sheets

Alan Cooper's viz of code as a steep and tottering deck of cards

My FEM post

structure

what the building blocks of software are

how they're combined

sw is linked pieces of code

that can be brittle

or flexible

sw can have stability

Notions of stability

structural stability: will it stay up?

stability under load: Will it stay up with 1MM hits?

sequences add height, modularity adds width

That is, every subroutine call adds to the width of the routine (think activity diagram)

and therefore reduces the overall height

thus, the lesser area (h x w), the better structural stability

crucial bit: its a *subroutine call* not a subroutine itself

this implies a passive and active dual for a subroutine - its definition and an actual call

my original idea was to define a subroutine call as a "dense" point

...but maybe i should treat subroutines as blueprints and just replace their call sites with replicas of the defnition and just add up h x w?

"Blake canonical ordering" as the model of stable code, and by extrapolation: instability as a lack of it

combined: stability = conceptual stability + build stability

where conceptual = h x w

and build = breakage ladder

adv: this can represent both production and WIP code

consider a unit line, box or cube as representing stability

then 0 or (0,0) or (0,0,0) => completely stable

and (1,1,1) => completely unstable

alternatively we can take 1/x to get natural meanings

effort to remove a piece of code from its base can be thought of as "escape velocity"

ways of thinking about the building blocks

they are bricks stacked one on top of the other

they are pipes connected to each other through which data flows

combination: they are like bricks for static analysis

and pipes for dynamic analysis

it also helps to think of new statements jacking the older ones up
and the structure being built by continously pushing pieces upwards

This also jives with the notion of "higher up = less stable"

AND that of starting the execution at the top

forces on the structure

change

how software changes

how this impacts the structure

the agents of change

build-time constraints

functional requirements

non-functional requirements

political forces

developer preference

i dont like language x, i prefer y

language x does y like this, not this (idioms)

i dont do threads, i prefer actors/event loops/X (arch patterns)

they affect the static nature

from the outside - as things that change the structure

they affect the dynamic nature

from inside, as characteristics of the flow -eg, load

forces are more likely seen than felt ie, you see the effects of the force than the force in action itself

Questions expected to be answered

Is this piece of software stable? Flexible? Brittle?

Can I define how complex a system is based on its code?

how can I use this to develop a plan to understand it?

What is important/core?

What is large in size?

if I change X, what will happen to the software?

How much change of X can the software take before it breaks?

What is the cost of changing X?

How did it reach its current state of stability/flexibility/brittleness?

All definitions are "at a certain level" defined by a human observer called the "user"

code and data are the two basic types of "things" in software

~~code is active, data is passive~~

So what about data stored in memory vs disk? Is one active and the other passive?

Can we unite quote/unquote and load/store into one single paradigm which flows from active data to passive data?

TBD

code is a structure, a container; data is what is contained or passes through code

code can be changed to data and vice versa

code becomes data when it is ABSTRACTED

aka quoted

this is akin to making a blueprint from an existing building

this is fine for data that actually IS code; what about pure data?

Current answer: all code is data and vice versa. The container/contained dual is sufficient for our purposes

data becomes code when it is REALIZED

aka evaluated

this is equivalent to making a building from the blueprints

So to represent execution - which is the building being actually used?

statements are the atoms of code

they have context and a user at their level

meaning at a level above them

implementation at a level below them

so statement can be represented as: s: (M,C,U, B)

M: Meaning - facts/ s^1

meaning is always orthogonal to Base and the set of executors made available

meaning is expressed in an informal way eg, English, to denote that its not directly amenable to mechanical processing

it is possible to ascribe FOPL (or even imperative) semantics to meaning.Some gain in higher-order calculation is obviously possible, but Godel's limits render it eventually pointless.

the point of representing meaning is that processes occuring inside the user's mind can be modeled as being contained in it

C: Context: (I, E, O, S)

I: Input: Inputs to the statement

E: Executor: the part of the base that knows how to execute the statment

O: Output: Outputs from the statement

S: Side effects: Impacts to the context as a result of executing the statment

U: User: who observes, optionally provides input and/or on whose behalf the execution happens

B: Base: (Eb, Sb)

A Base B is a collection of executors Eb that can execute a set of statements Sb

gravity (g_B): an arbitrary number that denotes the size of the base

g_B= c1 * |Eb|, where c1 is a measure of the overall "icebergness" of the base.

g_Bshould be used as a measure of comparing two bases.

Should this be just a spl case of branch? TBD

Quote

Eval

properties of statements

static

h: height: distance from the base in count of statements

1 for statements

statement aggregates will obviously have >1 height

m: static mass: "amount of space" taken up by the statement

=1 for statements

w: weight: mass x gb

this just seems cool. but will it be needed? tbd

s: speed: Big O of the statement wrt the context

alternately, using the pipe model, 1/speed would be the resistance to flow

More work on this when I reach the dynamic parts

Fi: fan in: the number of unique inputs to the statement

Fo: fan out: the number of unique outputs to the statement

E: effects: the number of unique side effects due to its execution

c: complexity = (7*E + sgn * ( 2*Fo + Fi))/7

where sgn = ((E+1) mod 2) * ((E+1) - E^2)

this has a range of [0,1]

Measure of how difficult the statement is to understand

Less is better

Note: fact, function and proc are used below for latent meaning. Statemnts are NOT actually any of these

effects | outputs | inputs | c7y | comment

= = = = = = = = =====================

N | N | N | 0 | No impact at all - not a statement

N | N | Y | 1 | NOOP

N | Y | N | 2 | Fact

N | Y | Y | 3 | Fn

Y | N | N | 7 | Proc Proc

Y | N | Y | 6 | NOOP Proc

Y | Y | N | 5 | Fact Proc

Y | Y | Y | 4 | Fn Proc

sim: simplicity: 1-complexity

note: i originally called this understandability

S: stability

=1 for statements

i thought for long about measuing stability of individual statements, but it seems to me after some thought that instability comes from the incorrect/complex combination of statements rather than the statements themselves.
Hence moving calculated stability to the aggregates

f: flexibility: Fi/(Fi+Fo+Fe)

Measured as how many ways there are to influence the output

Therefore, the larger the input options, the larger the flexiblity

dynamic

state: passive, loaded, active, done

execution frame: sum total of the running context state

md: dynamic mass: "amount of space" taken up by a running instance of the statement

Space complexity of the statement wrt the context

changes on statements

statements can be aggregated to increasingly nested superstructures

For eg:

Sequence of statements

This is a set of statements that are executed in exact order

s = s1 , s2 implies

M = M1 & M2

where "&" implies a merge of the two meanings that is undefined at this level, but defined at the +1 level

C = C1 + C2

where "+" implies that the states of both contexts have now merged such that:

I: input of the sequence is the union of both individual inputs

O: output of the sequence is the union of both individual outputs

S: Side-effects from the first statement are superimposed upon by those from the second statement

U = U1 or = U2 or not at all

ie the user becomes pertinent only when the input and output are directly tied to the user

B = B1 = B2

where "=" implies that Base 1 and 2 are equivalent, ie

they are the same

or, they both support s1 and s2

B supports s if there exists an executor E for s in B

h = ∑ h_i

ie, height of the sequence is the sum of individual statement heights

S

stability decreases as the height of the sequence does

exponential function of h tbd

other properties tbd

s = s1, s2, ...., sn

extrapolate from binary logic above

Parallel Statements

s = s1 || s2

Routine - a group of statements

Component - a group of routines

this is a collection of related routines that may/not depend on each other

Application - group of components

this is a group of components orchestrated together to achieve a set of goals defined in the M domain

there is a user attached to the sytem

there is a feedback/control loop between user and application

What about process or machine boundaries?

Well, that's what the executor is! to be expanded from Seq onwards

Todo: When drawing multiple stmts with a single executor, box them together and write the executor on a corner

Properties of aggregates

height is the sum of the child elements' heights

stability is defined in a ladder

straight seq: = exp decrease as height increases

parallel stmts = min(stability of individual stmts)

routine = compound stability of child elements

component/application = function of # layers, size of each layer etc

Changes on aggregates

|||ly data can be atomic or aggregate

atomic data

has a value

and a base where its valid

aggregate data

notes

Can Bob Martin's SOLID priniciples be included here?

In particular the Stability principle and the "Main Line" concept?

Nice idea of modeling change as a "probability p of x changing" from this blog post

CAR Hoare's Theories of Software is also a good source

Found the wonderful "Grand Unified Theory of Software Engineering" book a week ago. Lots of overlap with my ideas.
Need to figure out how to merge mine with those. Initial thoughts:
- GUTSE is a much higher level thought process ie encompasses more.
- Does NOT want to get down to notation and symbols for valid reasons
- Has some awesome chapters on applying the theory esp using ACT-R. My theory should reach that level for it to be "done"
- to clarify, however: not trying to use ACT-R and such like. I just want to use the theory I come up with.
- Hadnt heard about ACT-R but seems like that would be an awesome tool in and of itself to understand the human side of software.

how to read this mindmap

the top level is unfolded to provide the most readable overview (imo)

each node's children can be read from top to bottom as a paragraph or cohesive whole

each child node with chidren can be further expanded to read that sub topic in the same top-to-bottom fashion

Eg: the "big idea" node opens out into 4-5 nodes that can be read as a sentence starting at "Define code..." and ending at "determine their value"

The left side of the map is roughly the "ideaspace" where incubation of ideas are added first

The right side is the more concrete side; representing thoughts that have been solidified enough to be called part of the theory

but this is a guideline, mostly. I typically add stuff to the left when I get stuck on the right.

status

basic elements for code and data decided

basic idea of stability still being worked on. was defining subroutine calls as "dense" points, and therefore defining the stability of the app as a volume-based CG-ish concept

the data hierarchy needs to be expanded

...as does the dynamic flow

if you're reading this months after feb 2012, read the left nodes first, then the "statements are atoms" one..

... and re-read the GUTSE book