In 1641, Evangelista Torricelli discovered something that baffled his contemporaries. He described a geometric solid formed by rotating the curve y = 1/x around the x-axis, from x = 1 to infinity. The resulting shape, now called Gabriel's Horn or Torricelli's Trumpet, has a finite volume (exactly π cubic units) but an infinite surface area.[1]

You can fill it with paint. But you can never paint its surface. The volume converges while the surface diverges. It's a shape that contains a finite amount of space wrapped in an infinite skin.

This paradox has a name in mathematics: the painter's paradox. And it has a name in software engineering too, though we don't usually call it that. We call it maintenance burden. Or feature creep. Or technical debt. Or, most honestly, the reason your SaaS bill goes up every year while the product does roughly the same thing it did in version one.

The Finite Core, the Infinite Surface

Every software system has a core value proposition. A word processor lets you write documents. A database stores and retrieves data. A messaging app sends messages. That core is the volume of Gabriel's Horn: finite, bounded, and largely stable after the first few releases.

But the surface area of a software system grows in ways that are harder to contain. Each feature adds integration points, test cases, documentation pages, and support tickets. Each API endpoint creates a contract that must be maintained. Each user-facing option multiplies the configuration space that QA must cover. Each platform you support (iOS, Android, web, desktop, API) multiplies the surface again.

A compact glowing core surrounded by an ever-expanding web of connections, integrations, and tendrils stretching outward, representing finite core value enclosed by growing maintenance surface area
The core value converges early. The surface area of maintenance, integrations, and edge cases keeps expanding.

The relationship between core value and maintenance burden often follows Gabriel's Horn's geometry. The value converges early. The surface area keeps expanding. Fred Brooks identified a version of this in 1975 when he described the "second system effect": the tendency for a team's second project to be overengineered, bloated with features that the first system's constraints had wisely excluded.[2] The core problem the system solves hasn't changed. But the surface area of ambition has grown without bound.

Backward Compatibility: The Infinite Obligation

Few things illustrate the Gabriel's Horn dynamic better than backward compatibility. When a platform commits to supporting old APIs, old file formats, or old behaviors, it takes on a surface area obligation that compounds over time.

Microsoft Windows is perhaps the canonical example. Raymond Chen, a longtime Windows developer, has documented hundreds of cases where modern Windows code contains workarounds for software written decades ago.[3] A bug in SimCity's memory management that happened to work on Windows 3.1 required a special compatibility shim in later versions. Applications that relied on undocumented behavior had to be accommodated. Each of these workarounds adds surface area: code that must be maintained, tested, and carried forward, even though it contributes nothing to the core value of the operating system.

The volume of what Windows does (run applications, manage hardware, provide a user interface) has been roughly stable since the mid-1990s. The surface area of what Windows must maintain has grown with every release, every third-party dependency, every compatibility promise. Finite volume. Expanding surface.

The SaaS Pricing Paradox

Gabriel's Horn offers a lens for understanding why SaaS pricing tends to rise while core functionality stays flat.

Consider a typical business productivity tool. Version 1.0 solves the core problem. Versions 2.0 through 10.0 add integrations, analytics dashboards, admin controls, compliance features, SSO support, audit logs, and AI-powered suggestions. Each addition expands the surface area: more code to maintain, more infrastructure to run, more security vulnerabilities to patch, more documentation to update.

The customer's core need hasn't changed. They still want to do the same fundamental thing they wanted in version 1.0. But the vendor's cost to maintain the product has grown substantially, because surface area compounds. The price increases aren't arbitrary. They reflect the Gabriel's Horn geometry of software: the cost of maintaining the surface grows faster than the value of the volume it encloses.

Stacked layers of software versions rising like geological strata, each layer thinner in new value but wider in surface complexity, with cost indicators growing along the edges
Each version adds a thin layer of new value atop an ever-widening foundation of maintenance cost.

Research from the Standish Group has consistently found that maintenance and operations consume 60-80% of total IT spending, dwarfing new development.[4] That ratio is Gabriel's Horn in a budget spreadsheet. The finite volume of new value creation is wrapped in an ever-expanding surface of maintenance costs.

Microservices: Surface Area by Design

The microservices architecture pattern is, in Gabriel's Horn terms, a deliberate trade of volume for surface area.

A monolithic application has a relatively small surface area: one deployment, one codebase, one set of dependencies. Breaking it into microservices multiplies the surface. Each service boundary creates network latency, serialization overhead, a new failure mode, a new deployment pipeline, a new set of logs to monitor, and a new API contract to version.

For large organizations with hundreds of engineers, the trade-off often makes sense. The surface area cost is justified by the ability to deploy and scale services independently. But for smaller teams, the surface area can overwhelm the volume of value. A startup with five engineers running twenty microservices may spend more time managing the surface (service mesh, distributed tracing, API gateways) than building the core product.

Martin Fowler's "MonolithFirst" advice captures this intuition: start with the finite volume of a monolith, and only expand the surface area into microservices when the organizational need justifies the cost.[5] Gabriel's Horn suggests the same thing. Don't expand the surface until you're sure the volume warrants it.

Open Source and the Maintainer's Horn

Open source software exhibits Gabriel's Horn dynamics with particular clarity. A maintainer creates a library that solves a specific problem (finite volume). The library gains users. Users file issues, request features, submit pull requests, and report security vulnerabilities. The surface area of maintenance grows with adoption.

Nadia Eghbal's research on open source sustainability documented this pattern extensively. Popular projects often have a small number of maintainers supporting a vast surface area of users, issues, and dependencies.[6] The core library hasn't changed much. But the maintenance burden has grown to the point where volunteer maintainers burn out, step away, or simply stop responding.

The Log4Shell vulnerability in December 2021 illustrated the consequences. Log4j, a Java logging library maintained by a handful of volunteers, contained a critical remote code execution flaw that affected hundreds of thousands of systems worldwide.[7] The volume of what Log4j does (log messages) is modest. The surface area of its deployment, its dependency chain, and its security exposure was enormous. Finite value, infinite responsibility.

The Rewrite Calculation

Gabriel's Horn reframes the perennial "rewrite vs. maintain" debate in engineering.

A rewrite promises to reduce surface area by starting fresh: clean code, modern architecture, no legacy baggage. But the new system must eventually support the same features, integrations, and edge cases as the old one. The surface area doesn't disappear. It gets rebuilt, often at great cost, and then begins expanding again.

Joel Spolsky's famous warning against rewrites, written in 2000, is essentially a Gabriel's Horn argument: the old code's complexity isn't accidental. It represents years of bug fixes, edge case handling, and hard-won knowledge about the problem domain.[8] That complexity is surface area, and it will reassert itself in any replacement.

The wiser approach, in many cases, is to manage the surface area rather than try to eliminate it. Deprecate unused features. Prune dead code. Reduce the API surface. Simplify configuration options. Each of these is an act of surface area reduction that preserves the finite volume of core value.

Living with the Horn

Gabriel's Horn teaches a counterintuitive lesson: you can have a shape with finite content and infinite boundary. Software teaches the same lesson: you can have a product with finite value and infinite maintenance cost.

The wisest engineering decisions often aren't about what to build. They're about what surface area you can afford. Every feature, every integration, every platform, every backward compatibility promise expands the surface. The volume of value it encloses may not grow at all.

The question isn't "can we add this?" It's "can we maintain this?" Not "does this feature have value?" but "does this feature's value exceed its surface area cost, compounded over the lifetime of the system?"

Torricelli's trumpet can be filled with π cubic units of paint. But painting its surface would require an infinite amount. The best engineers know which side of that equation they're on, and they choose their surface area accordingly.

References

[1] Evangelista Torricelli, Opera Geometrica, 1644. For a modern treatment, see Paolo Mancosu and Ezio Vailati, "Torricelli's Infinitely Long Solid and Its Philosophical Reception in the Seventeenth Century," Isis, Vol. 82, No. 1, 1991, pp. 50–70.

[2] Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering, Addison-Wesley, 1975, Chapter 5: "The Second-System Effect."

[3] Raymond Chen, The Old New Thing: Practical Development Throughout the Evolution of Windows, Addison-Wesley, 2007. See also his blog: https://devblogs.microsoft.com/oldnewthing/

[4] The Standish Group, "CHAOS Report," various years. Summary data widely cited in IT management literature. See also Robert L. Glass, "Frequently Forgotten Fundamental Facts about Software Engineering," IEEE Software, Vol. 18, No. 3, May/June 2001, pp. 112–111.

[5] Martin Fowler, "MonolithFirst," martinfowler.com, June 3, 2015. https://martinfowler.com/bliki/MonolithFirst.html

[6] Nadia Eghbal, Working in Public: The Making and Maintenance of Open Source Software, Stripe Press, 2020.

[7] Jen Easterly, "Statement on Log4j Vulnerability," CISA, December 11, 2021. https://www.cisa.gov/news-events/news/statement-cisa-director-easterly-log4j-vulnerability

[8] Joel Spolsky, "Things You Should Never Do, Part I," Joel on Software, April 6, 2000. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/