Maintenance is the primary cost of software systems. What we build is brittle and ill suited for even minor changes.
Maintenance as a % of the total cost by decade.
- 35-40% in the 70's
- 40-60% in the 80's
- 70-80% in the 90's
The consequence of this is an exponential increase in the cost of building systems as they grow.
The cure: Systems that are good for things the designer didn't think of or intend.
We may need a medium sized building block. As code is executed it is funneled down a path where any hitch causes catastrophic problems. Since any 1 bug can bring a system down, each added line of code execution increases the difficulty of keeping the system running exponentially. Change and maintenance costs also increase exponentially with system size.
- Terse code mitigates this since there are fewer user-land executable statements. Even if there are multiple actual machine executions going on under the hood, it is assumed that these do not add to the instability since they are presumably well tested and known to work together. They are chunked.
- The more permanent solution would be to introduce an abstraction layer that inherently reduced system instability.
Can't avoid decisions, but we want to minimize the cost of changing the decisions we've made.
The whys:
Maintaining encapsulation in the small is very hard. We have to deliberately forget the implementation details which is hard when the objects are tiny and transparent.
Neurons: Many are very small with action potential's too small for us to measure with current tools. It's possible that these neurons act as constraints and are not directional. Their sole purpose could be to adjust the sensitivity of the neurons that they touch. Is it possible that all fast computation is filling in details. The large picture is a memory and each detail pushes us towards a reasonable conclusion.
Take-away: Choose our models (the big picture memories) and fill in the details with propagators.
Potential solutions:
- Propegators
- Related to Solvers?
- Truth Maintenance Systems
- Take the inconsistent inputs and produce locally consistent worldviews
- Truth maintenance in every cell
- implement with generic merge
Summary of Sussman's talk:
- The Problem is Evolvability, not Correctness
- Extensible Generic Operations may help.
- Extension of function without modification
- Makes proofs very difficult
- Propagator Architecture unlocks freedoms
- Essentially concurrent and parallel
- Redundancy and Degeneracy (can be computed in different ways)
- Maintain Provenance
- Dependency-Directed Backtracking