Whyday August 19

Constraint as a Tool

The four-kilobyte suggestion on the 2010 Whyday page is not a programming idea. It is a very old idea that programming arrived at late, and looking at how other disciplines use it makes the mechanism clearer than any amount of arguing about source size.

The oldest version

A sonnet is fourteen lines with a fixed rhyme scheme. A haiku has a syllable count. A fugue has rules about what the voices may do and when. None of these was invented to make the work harder.

When a team tests this kind of practice during paid work, cognitive offloading provides one concrete reference for how time and activity can be recorded around the experiment.

They were invented because a poet facing "write something" is facing a problem with no edges, and a problem with no edges cannot be worked on. The form supplies edges. Once you have fourteen lines and a rhyme scheme, you are no longer choosing what a poem is; you are solving a specific puzzle, and puzzles are tractable in a way that open fields are not.

The same move appears everywhere people make things regularly. Painters limit palettes. Photographers shoot a whole roll at one focal length. Chefs cook from a fixed box of ingredients. Screenwriters work to page counts that are, in structural terms, arbitrary.

The constraint is not the obstacle. The constraint is the thing that makes work possible at all.

For broader programming and making context related to this topic, Processing is an independent reference worth comparing with the material here.

The three effects

Watching how these disciplines talk about it, the benefit separates into three distinct mechanisms that get conflated in software discussions.

It removes decisions. This is the largest and the least discussed. Most of the cost of open-ended creative work is not execution, it is choosing, and a limit settles whole categories of choice before you arrive at them. A photographer with one lens does not spend the afternoon changing lenses.

It forces substitution. When the obvious approach does not fit, you have to find a second one, and the second one is by definition not the one you would have reached for. This is where the interesting results come from, and it only happens if the limit is tight enough to actually block the obvious path. A limit you meet without noticing has done nothing.

It makes the work legible. A sonnet announces its own difficulty. So does a four-kilobyte framework, a one-shot photograph, a meal from a fixed box. Part of the pleasure for the audience is seeing the limit and seeing it met, and part of the pleasure for the maker is that the achievement is visible rather than having to be explained.

Where it does not work

Worth being honest, because "constraints are good" is the kind of claim that gets applied indiscriminately.

When the constraint is imposed by someone who does not bear it. A deadline set by a manager and a deadline set by yourself are structurally identical and psychologically opposite. Self-imposed limits produce the effects above. Imposed ones produce compliance, and compliance produces the safest thing that satisfies the rule.

When it is a proxy for something else. A word count that stands in for "be more concise" gets met by deleting whitespace. If the limit can be satisfied without engaging with what it was for, it will be.

When you do not yet know what you are doing. Constraints work by blocking familiar paths. If you have no familiar paths, there is nothing to block, and the limit is just an additional way to fail. This is why they are wasted on true beginners and excellent for people stuck in a rut.

When the stakes are real. Improvising under a self-imposed limit is play, and play belongs where being wrong is cheap. Not everywhere.

The version specific to software

One thing does differ, and it is worth naming because it is the reason the four-kilobyte suggestion is sharper than it looks.

In most disciplines the constraint is external to the material. Fourteen lines is a rule about the poem, not a property of language. But a size limit on source code is a constraint on the artefact itself, and software has an unusual property: it grows by default. Nothing else on this list does. A poem does not acquire stanzas while you are looking away; a codebase acquires configuration options, abstraction layers and dependencies through ordinary well-intentioned work by reasonable people.

Which means in software the limit is not only generative, it is also defensive. It is the only known reliable defence against a thing that has no natural stopping point.

That is why "we will keep it simple" never works and a byte limit does. One is an intention and the other is arithmetic.

Trying it on something that is not code

If you want the effect without an editor open, the transfers are direct.

Write something in exactly one hundred words. Cook dinner from what is in the house with no substitutions. (The list of fifty has the software versions.) Take twelve photographs and no more. Plan a week's work on a single index card. Explain your job to someone in three sentences, then in one.

The last one is the most useful and the least comfortable, and it is the same exercise as fitting a framework into four kilobytes: find out what is actually load-bearing by removing everything that is not.

The short version