The Master Programmer: Stable vs Volatile Code

The master programmer continuously partitions code into that which is stable and that which is volatile.

Volatile components stay at the top where dependents are minimized.

So the master programmer creates a software component architecture that look like this (directed edges are dependencies¹):

An Ideal Architecture

It may take some time to find the stable parts, to carve them out from the volatile.

So the master waits for the stable parts to prove themselves. She lets volatile code accumulate. At the top, they grow a little:

An Optimal Architecture

But she is vigilant. In short order she will discover the stable parts and factor them out, shrinking the volatile components back to healthy size:

An Optimal Architecture Iterated

Her goal is to keep the volatile parts minimized. This is the part that costs.

The non-master cannot do this. Unable, she makes one of two mistakes.

The first mistake is calling stability where it does not exist by creating a volatile dependency. This is known as premature abstraction.

The choice is devastating to productivity. All dependents are infected and volatility and cost are increased all around:

An Optimal Architecture Iterated

The other mistake is more forgivable. This programmer understands her ineptitude. She knows she doesn't understand the game and so refuses to play. She simply lets volatility increase at the top:

An Optimal Architecture Iterated

But for too long. And the end result is the same: too much volatility, too much cost.

The natural gravity is toward chaos. To volatility.

Without mastery, without vigilance, the progression is expansion.

The center becomes increasingly difficult to hold. The event horizon is always reached much sooner than expected:

The Event Horizon

The event horizon is the point of no return. All that can be done is to start over. This is called The Rewrite. The Rewrite is horribly expensive, often fatal.

Sadly, this is the industry norm.

Why?

Because there are so few masters.

And why is that?

Because mastery comes by long, strenuous effort. One needs to fail and try and fail again—at separating stability from volatility in this way that we are talking about.

It is an earned skill requiring much focused and repeated practice, and much failure.

It's like swinging a tennis racket. It's not enough to know the form, you have to internalize it. The difference between mere knowing and ability are miles apart.

Very, very few go through the regimen.


Footnotes

  1. This diagram and our story applies to every level of your system composition: to functions within source files, to files or classes within packages, to packages within modules, to modules within sub-systems, and to sub-systems within systems.