Physics of Software, the Blind and the Elephant

In The Simpsons' Chapter 28 Homer designs a car with all the features he likes.

"The Homer" has no conceptual integrity and is a total failure, but it is still a car.

There's a limit to how many isolated features can be added to a car before it stops looking and behaving like a car.

Software doesn't work like that.

The laws of physics also constrain what a car can be, there are limits to the shape and size of a car.

Shape and size aren't constraints in software.

Inside the solution space of viable cars there is physical property that helps the design process: the entire car can be seen at once.

Seeing all at once lets people find out if it reflects one set of ideas or it contains many good but independent and uncoordinated ones.

Software can't be seen all at once, not by looking at its code nor by using it, that removes a limit that physical things have.

We can keep adding features into software without noticing any effect from the only perspective we have, a local perspective.

Software is like the fable of the blind and the elephant, at any given moment we are seeing a small slice of the whole, trying to figure out the global shape and how everything interacts and fits together.

The real world limits how much complexity we can add to a design before it "collapses under its own weight".

As software grows in complexity analogs to friction and inertia increase.

Friction in software happens when a change produces an opposing force in the shape of bugs or broken code.

99 bugs in the issue tracker, 99 bugs. Take one down and squash it, 128 bugs in the issue tracker.

Inertia in software happens when a change requires a large amount of preliminary work, refactors, tests, waiting and bureaucracy.

A good measurement of inertia is how long it takes from the moment you have an idea to the moment you make the required changes and see it reflected in the running application.

Software collapses under its own weight when the amount of energy we put in is larger than the value we get out.

Constraints similar to the physical world along with their units, measurement devices and operational limits may help avoid the worst effects of complexity in software.

Being able to "see" software "all at once" may allow the comparison of different designs and finding out when a design starts losing conceptual integrity.

Or maybe this is just a bad analogy :)