The Cavity Model of Software Development

Imagine that you’re a dentist with a cavity to fill. You can clean up the cavity a little bit but ultimately the cavity is going to have whatever shape it has. Your job is to fill the cavity and get the best fit between the filling and the surface of the cavity so the filling stays put and the cavity doesn’t get bigger.

Now imagine that instead of a dentist, you’re a programmer with an app to build.

The shape of the cavity defines the problem domain for your app. Your solution will try to snugly fit that problem domain. If things fit well your stakeholders will get a lot of value and their problems won’t get worse.

Each nook and inflection in the cavity represents a specific problem to solve.

The dots are features. The features follow the shape of the problem domain. The dots – the features – connect the solution to the problem domain. They approximately address each problem. Some features get closer to solving a problem than others.

Each line represents the implementation of a feature. The longer the line, the more complicated the feature is to implement. Complexity could be measured in units of time, estimated points, or some other metric.

Here’s a common application:

Luckily we don’t have to build everything ourselves. A lot of work is handled by the operating system and the database. Libraries and frameworks help too. The rest is up to us. “Custom code” is where most features are realized.

The code that we write lives closest to the problem domain, but notice that the implementation (squared lines) never quite perfectly fits the problem domain (natural curves). A close approximation is often possible and in actual practice is usually sufficient.