A Calculus for Software

Uncle Bob introduces the need for Calculus with Zeno’s Paradox regarding Achilles and the tortoise:

While it was intuitively clear that Achilles would pass the Tortoise quickly, the algebra and logic of the day seemed to suggest that the Tortoise would win every race given a head start. Every time Achilles got to where the tortoise was, the tortoise would have moved on.

The paradox highlights a limitation in algebra, and inability to deal with infinity. Calculus provided a way of dealing with infinity that overcame this limitation and provided a means for solving a whole new set of problems.

There is an equivalent paradox in software development, and the calculus for software development must be able to resolve it.

He is right, we cannot keep piling complexity upon complexity, and sometimes that means more than simply writing better code, it means writing no code at all. This means that we cannot look to programming languages or architectures for the next step because they exist to serve the purpose of writing code or building systems. Sometime we want to do neither, sometimes it is better to do nothing. Another discovery in mathematics even more fundamental than calculus was the discovery of zero, a way to represent nothing. In software development we need a method that enables us to produce nothing.

This means that Model Driven Architecture, 4GL Database Languages and Quantum Computing cannot be the answer. These are all advances that seek to provide a new way to write code, or have it generated or executed. They are still, fundamentally, about producing code. Calculus did not provide a new way of doing algebra, if didn’t even make possible things that had been impossible using algebra. While Issac Newton used his own idiosyncratic form of calculus to solve problems, he would translate the resulting ideas into a geometric form that his readers would more readily accept. It provided a new way of thinking about problems.

The monster to by slain is complexity, but there is no silver bullet left that will allow us to put the beast to rest. There are two types of complexity: essential and accidental. Essential complexity is unavoidable, as Brooks explains:

The complexity of software is an essential property, not an accidental one. Hence, descriptions of a software entity that abstract away its complexity often abstract away its essence. For three centuries, mathematics and the physical sciences made great strides by constructing simplified models of complex phenomena, deriving properties from the models, and verifying those properties by experiment. This paradigm worked because the complexities ignored in the models were not the essential properties of the phenomena. It does not work when the complexities are the essence.

If the complexity of software is all essential, then is there no hope for improvement? Back in 1987, when the essay was written, Brooks concluded by looking forward to what was to become Agile:

Therefore, one of the most promising of the current technological efforts, and one that attacks the essence, not the accidents, of the software problem, is the development of approaches and tools for rapid prototyping of systems as prototyping is part of the iterative specification of requirements.

It was the development of rapid prototyping and iterative development, in RAD and DSDM, that laid the foundations for the Agile movement. Principles like Test Driven Development and YAGNI help us to avoid writing code that did not need to be written.

The question now is what next? What is the next method for attacking the essential software problem while ensuring that the accidental problems do not return? Personally I look to the principle of Lean for inspiration, not for new ways to write code but for new ways to see the problems that the code is attempting to solve.