How do we add gravity to software?
18 November 2008 | Matt Perdeaux | Technology & applications
"When you blow something up by a factor of one hundred, it gets weaker by a factor of one hundred. If you try to build a cathedral that way, it just collapses into a pile of rubble." - Alan Kay
Having spent time as both a "Software Engineer" and a Structural Engineer, I am always interested when key industry figures start comparing the two disciplines. Alan Kay's insight into one of the fundamental problems with software reminded me of the arguments over the use of the word "Engineering" for software.
"'Software Engineering' is something of an oxymoron. It's very difficult to have real engineering before you have physics, and there isn't anything even close to a physics for software" - L. Peter Deutsch
The more I think about it, the more I can see what these guys are saying. Within the idiom, software isn't subject to the physical laws that govern structures.
For instance, about a decade ago, I was tasked with building the structural analysis model of the London Eye. As you can imagine, this included a very thorough consideration of the different combinations of force and load acting on the structure in order to calculate how much material was required for it to stand up. We considered over 200 different loadcases for self-weight, wind, people, motion, etc. but in all of them the major force was due to the self-weight of the structure. On average, about 90% of the material in that big wheel is only there to hold itself up.
This introduces some interesting approaches to the engineering solution. In these circumstances, if you have a large force to resist, you cannot just throw more material at it because you are just worsening the problem. Eventually the whole thing will fall down. One wonders what kind of software we would produce if, like London Eye steelwork, 90% of the code written did nothing apart from retain the structural integrity of the software. Without the constraints of gravity, won't we just keep on building and building?
I guess we apply some constraints to ourselves by using application frameworks such as Rails or Django, but the only real physical constraint on sheer volume of code I can see is factors such as disk space, processor speed, RAM, etc. And how many of us push our servers to that extent? Hmmmm.
By contrast, software has almost no mass and computers exert almost no force, so very large gossamer constructions can be made. Because our nervous system has real difficulties with most time scales, and because the danger to humans is much less manifest (though quite there), we miss that today's software is slowly falling down and failing in other ways that are quite dangerous.
The rare engineers who are highly motivated by aesthetics as well as "just getting the requirements met" will often make great software; the majority are making slowly crumbling Egyptian pyramids.
The new property that shows up to take the place of bad structural integrity is "cosmic complexity", and this has its own ways to spawn disasters and otherwise cause people great difficulties and incur great costs of many kinds.
Best wishes,
Alan
18 Nov 2008 at 11:25 AM | Alan Kay
All a Structural Engineer can do is produce a set of calculations and drawings that represent an abstraction of the final building. Additional processes of fabrication and construction actually create the building, and anything too complex is often very expensive to fabricate, or impossible to construct on a windy building site at sub-zero temperatures.
The "Software Engineer" carries out all the fabrication and construction themselves, and has none of the limitations associated with the transport or additional material costs of complexity.
18 Nov 2008 at 04:30 PM | Matt Perdeaux