Mathematics

A sphere is efficient because it balances what it holds with what it exposes. To make the analogy practical, we must describe that balance with numbers. Geometry already provides the blueprint: the relationship between volume and surface.

From Geometry to Structure #

In geometry, the sphere of radius r has^[1]:

  Volume (V) = (4/3) × π × r³
  Surface (A) = 4 × π × r²

The ratio of these two quantities — V to A — measures how efficiently the sphere contains its contents. As the radius grows, volume increases faster than surface area, meaning larger spheres store more with less exposure per unit.

In design, the same logic applies. A module can hold internal complexity (its volume) and expose an interface to the world (its surface). The most stable modules minimize exposure for a given amount of internal logic.

Defining Volume and Surface in Code #

For software systems, we define two structural measures^[2]:

• Internal volume (V) = number of internal elements × cohesion factor
• Interface surface (A) = number of public interfaces + external dependencies

Cohesion captures how well internal elements belong together. Dependencies measure how much the module leans on others. Together, they describe the same relationship as pressure and surface tension in physics.

When internal cohesion increases faster than exposure, the design becomes more spherical. When exposure grows faster than cohesion, the surface expands, and the structure loses stability.

The Sphericity Index #

To measure this balance, we define a dimensionless score:

S = V / (A^α)

where

• S is the sphericity index,
• V is internal cohesion-weighted complexity,
• A is interface surface,
• α (alpha) is a scaling factor, usually between 1.5 and 2, to adjust for system size.

Higher S means a design that contains more functionality for less exposure. Lower S indicates a structure leaking complexity through its boundaries.

This mirrors the isoperimetric inequality^[3] in geometry — the idea that no shape can enclose more volume with less surface than a sphere.

Interpreting the Formula #

If we double the internal logic without increasing interfaces, S grows. The module becomes denser but no harder to interact with. If interfaces multiply while logic remains constant, S falls. The system becomes fragile, spending more energy maintaining boundaries than purpose.

ΔS ≈ (ΔV / V) − α × (ΔA / A)

Small changes in cohesion or exposure shift the score dramatically.

This sensitivity reflects what every developer feels intuitively: a single unnecessary dependency can distort the entire shape.

Nested and Distributed Balance #

Each layer in a system — class, module, service — can be assigned its own S value. Inner layers tend to have high S (dense, stable). Outer layers should trade some efficiency for flexibility. When all layers together maintain roughly proportional S values, the system reaches dynamic balance.

In distributed systems, each service’s sphericity can also be measured: local complexity versus external connections.

When a service’s A grows too quickly, boundaries rupture, and the architecture fragments. When V grows without A adapting, the service becomes opaque and rigid. The stable zone lies between.

Toward Measurement #

This equation does not claim to measure beauty or taste. It measures proportion — the geometry of stability. The closer a module’s S approaches the theoretical efficiency of a sphere, the less effort is wasted managing boundaries.