Embrace constraints

Don't gloss over a routine or piece of code involved in the bug because you "know" it works. Prove it. Prove it in this context, with this data, with these boundary conditions.

— The Pragmatic Programmer, D. Thomas

The quotation is about debugging and contains, almost in passing, the best operational definition of a constraint I know. Look at the ending: this context, this data, these boundary conditions. What makes a claim about software verifiable is not its generality but its bounding. "This works" cannot be checked. "This works with this data, in this context, and at this boundary" can.

It is the same operation needed one level up, when what you are directing is not a routine but a product. And it is an operation the industry avoids with remarkable consistency, because the material we handle lets us avoid it.

A material that does not resist

Working with software has a peculiarity worth not naturalising: the material offers no resistance. A carpenter discovers the limits of a project by touching the wood; the piece has a grain, a size, and a tolerance, and those properties make decisions on their behalf. An architect has a plot, a load budget, and a building code. In those crafts, the resistance of the material is a free source of constraints.

In digital that does not exist. Almost everything is possible, nothing runs out by itself, and adding one more possibility rarely prevents any of the earlier ones in technical terms. It is the property that makes software an extraordinary tool and the one that makes product management a difficult craft: with no external resistance, nothing forces a decision. And where there are no decisions there is no design, only accumulation.

Hence constraints in digital product have to be imposed rather than found. It is deliberate, artificial, and somewhat disagreeable work, consisting of manufacturing the scarcity the material fails to provide. When someone says a team works better under constraints, they are not praising ingenuity: they are describing the only condition under which that team can finish anything.

The three constraints that do the work

They are not equally useful. Three of them, in my experience, do most of the work, and all three are uncomfortable for the same reason: they force you to give something up before you have complete information.

Fixed time. Turning estimation inside out — not how much time something needs but how much time you give it — changes the kind of conversation a team can have. With open time, the only available question is what is left to do. With closed time, the question that matters appears: what is the minimum that has to exist for this to be of any use. The second is a design question; the first is a list.

The perimeter. Deciding up front what stays out is cheaper than deciding it once things are built. And it is more honest, because when it gets decided during construction, what gets cut is not the least valuable thing: it is whatever happened to be left, which is a completely different category.

Appetite. How much this is worth spending, stated before you know what it would cost. It sounds imprudent and is the opposite: it is the only thing that allows comparison between initiatives that share no unit of measure. Without a declared appetite, any real problem justifies any expense, because it is always true that fixing it would improve something.

All of them are versions of the same thing. You are fixing the context, the data, and the boundaries so that the question becomes answerable.

The tradition that already knew this

There is a long genealogy behind this, and it comes from craft rather than management.

The Unix philosophy was built on a radical constraint — do one thing and do it well — that looks like a limitation and in practice was what made composition possible. A program that does one thing can be combined with another; a program that does seven combines with nothing. The constraint did not reduce the power of the system: it multiplied it, by moving that power from the component to the relationship between components.

Christopher Alexander arrived at the same place from design: the problem of designing does not consist of imagining forms, it consists of identifying the set of requirements the form must satisfy and the tensions between them. Without that bounded set there is no criterion, and without a criterion the choice between two solutions is aesthetic or political, never functional.

Ohno formulated it on the factory floor from an intuition contrary to the orthodoxy of his time: limiting inventory was not a consequence of having a good process, it was the mechanism that forced you to have one. With abundant inventory, any problem in the system gets cushioned and therefore stays invisible. The constraint acts as a developer fluid.

Bruno Munari, writing about graphic design, put it even more directly: well-posed problems already contain their solution. The designer's work lies in the posing, not in the inspiration. And posing consists, precisely, of constraining.

What the quotation is really asking for

Back to Thomas: the point is not debugging discipline, it is suspicion about what you think you know. Because you "know" it works — with the quotation marks placed on purpose. The routine you never check is the one holding the bug, not through bad luck, but because a bug survives exactly where nobody looks.

In product management the equivalent is the constraint nobody sets because it seems obvious. The assumption that this customer behaves like the others. The assumption that this metric means what its name suggests. The assumption that the agreed scope is the real scope. All of them are claims without boundaries, and every claim without boundaries is uncheckable.

Embracing constraints is not a frugal attitude or a hymn to austerity. It is accepting that you can only decide about what you have bounded, and that in a material with no resistance of its own, bounding is work nobody will do for you.

Which of your certainties about your product have you left untested because testing seemed unnecessary?