The surface area to volume ratio (SA: V) explains many behaviors across biology, chemistry, and physics. The ideas in this ratio can teach us about software.
Software products have two sources of complexity: the depth of the underlying code and the feature set that touches the userbase.
First, the software can have complex code under the covers. One could measure this in line-count, code paths, readability (Hi, Perl!), or exotic implementation. The product definition itself will drive a certain amount of code. But there is often a great deal of complexity on top of this minimum, particularly in indie or "maker" projects. People build a product as a way of learning some aspect of technology or scratching a methodological itch. The learning curve is visible in the codebase. Also, without an ex-ante blueprint, one bakes in unnecessary "flexibility" for later development.
None of this is necessarily bad! And I have discussed elsewhere how to manage this depth. For this exercise, I am treating the complexity of the codebase as "volume."
Second, a software product can have a complex feature set. A feature is an aspect of the software that touches the user. I think of this as the "surface area." Every point of information delivery and responsiveness increases the touchable plane. They fight against each other, too, creating bumps and arcs that I imagine like a folding protein. The way the whole product interacts with the world results from the sum of this surface area. And minor changes to the underlying structure can have a significant impact on how it "folds."
Unlike in nature, the surface area described here could be considered part of the volume since it is all code. The analogy does not have a perfect fit. But let us give it a little room to run.
The surface area-volume ratio (SA: V) describes a great deal of how materials interact. For example, in situations where SA: V is high, materials are much more reactive - there is more opportunity for them to connect.
For an everyday example, consider starting the chemical reaction we call fire: rough wood, paper, etc., are more flammable than their smooth counterparts. A nicely split log catches fire faster than finished furniture. Newspaper lights more readily than a glossy magazine. (This last example may age poorly)
Go to the beach and pick up a rock from the water. You will find it remarkably smooth. The water erodes surface area. It starts where it is easiest to make a change - the slight roughness on the surface. Over a long time, this wears away down to the slick, wet stone you hold in your hand.
In a more complex example, consider organic chemistry. Proteins - molecules with highly complex shapes - drive a great deal of the activity we call life. They are also fragile both individually and generationally. Smaller, simpler molecules are responsible for colossal forces in the universe. Hydrogen is the basis of nuclear fusion.
In software, volume and surface area can drive both cost and opportunity.
Where there is high volume and high surface area, one has a highly complex product. I consider this combination definitionally mature. The cost of evolving it will be high both technically and in the way users react.
Where there is high volume and low surface area, the product is a compute-heavy composable resource. The smaller surface area means that the responsibility for delivering value to the end-user is likely in another product, which creates some risk. The high volume means technical complexity remains high. If the problem domain is technically complex, this might be the right fit.
Where there is low volume and high surface area, the product is very front-end driven. This pattern can be a great consumer of the previous example: compose code-rich resources and focus on delivery. The risk is that it could be all hat and no cattle. For my money, this is a perfect domain for many of the existing no-code platforms. The diminished lifetime in nature of materials with high SA: V means that taking an approach that decreases the cost of generating the surface area has a lot of leverage.
Based on the preceding, it might seem ideal to be low volume and low surface area. It keeps costs down and focuses value. Except if there is no complexity, whence the value? Does one have a software product? There is value in businesses that keep these down, but then we start to think about a third element: human delivery. Otherwise, one might have a "feature" rather than a product.
One can bring down volume and surface area.
First, one can employ a more "service-ful" approach to reduce the technical complexity - volume - of a software product. Serverless enthusiasts bang this drum all the time. The point is not to remove the servers per se but to outsource technical concerns. Focus the development on where it is exceptional - the required technical complexity. If what is left is a low-volume product, that should speak to us.
Further, we should pay attention to the complexity of the outsourcing itself. Compositional code drives volume in the product in ways that some engineers are only beginning to understand - and others do not see at all. Increasingly, we will look to the DevOps code and configuration to understand the technology story.
We can deploy APIs and webhooks to reduce surface area while enabling more hooks for our customers to drive value. I have discussed this strategy elsewhere. Being more selective in which surface area components are required to make our software successful will smooth our stones.
Finally, I should acknowledge that the surface area and volume may not be sufficient to think about this problem. Geometry is weightless. In physics, we would consider mass. Mass, volume, and surface area combine to drive behavior. Any engineer with experience will say that software has inertia - the difficulty in change outlined above parallels inertia. So this topic is worth deeper interaction.
Software is complex. And that is a good thing! The complexity of software moves concerns off humans and permits us to accomplish goals that were impossible a mere generation ago. Managing that complexity is the task before us. Imperfect analogies to the tools that came before us in math and nature can help guide us. Even with their flaws, we gain an intuitive sense of what is right, what is valuable - and what will generate extraordinary returns.
Photo by Aaron Burden on Unsplash