Whyday August 19

The Four-Kilobyte Rule

The idea is much older than software. The 2010 Whyday page listed six suggestions, and one of them was oddly specific: choose a tight constraint — four kilobytes of source code, for example — and see what you can do inside it.

That number was not arbitrary. It is a reference to Camping, the web framework _why wrote whose entire source was kept to a few kilobytes. The constraint was the identity of the project. Camping did routing, controllers, views and database access inside a budget smaller than a single icon file, and it did them by refusing to do anything else.

For teams trying a short creative session inside a normal workday, remote workforce management software is one practical reference for keeping the experiment distinct from routine delivery.

Fifteen years later the number is still the best single piece of advice on that page.

What a constraint actually does

The problem with an open evening is not that you lack ideas. It is that every idea immediately grows. You think "small tool," and within twenty minutes you are choosing a config file format, because a real tool would have configuration. The scope expands to fill the time, and then past it, and then the evening ends with a directory structure and no program.

A hard limit closes that door before you reach it. Four kilobytes has no room for a config file format. It has no room for a plugin system, an abstraction layer, or an options parser with long flags. Every one of those decisions gets made for you, instantly, by arithmetic.

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

This is the underrated part: a constraint is not a restriction on what you can build, it is a way of not spending your evening on decisions. You get the hours back and spend them on the interesting thing.

Why the limit has to be uncomfortable

A budget you can meet without noticing is not doing anything. If the first version comes in at half the limit, the limit was decoration.

The useful zone is where you can see a working version in your head and it does not fit. That is where the constraint starts producing results, because the only way forward is to find something you assumed was necessary and discover that it is not. Most of the good ideas that come out of constrained work come from exactly that moment.

The reverse is also worth knowing: a constraint so tight that nothing works is just a wall. If you spend an hour and cannot get anything to run at all, loosen it and move on. The point is productive discomfort, not a puzzle.

Constraints that are not code size

Bytes are the classic, but they suit some projects and not others. A few that work as well, with forty-odd more here:

One file. No imports of your own code. This is size in disguise — it caps complexity without counting characters, and it makes the result trivially shareable.

No dependencies. Standard library only. You will rediscover how much is already there, and how much of a typical project is glue for things you did not need.

One screen of output. Whatever it is, it has to fit in a terminal window or a single page without scrolling. Forces you to decide what actually matters in the output.

Two hours. Time as the constraint rather than size. The advantage is that it caps the project regardless of what the project is. The disadvantage is that it is easy to cheat, so it needs an actual alarm.

One input, one output. No interactivity, no state, no menus. Something goes in, something comes out. Enormous amounts of the usual work vanish.

No conditionals. A deliberately strange one. Write something with no if and no ternaries. It sounds impossible and mostly is not, and it drags you into parts of the language you never visit.

Someone else's constraint. Ask a friend for a number or a rule before you start and do not negotiate it. Removes the temptation to pick a limit you already know you can meet.

Picking the number

Do this before you open an editor, because the constraint chosen mid-project is always the one you have already met.

Guess how big the finished thing would be if you wrote it normally. Halve it. If you have no idea how big it would be, that is a sign the project is not defined enough yet, and thirty seconds of thinking about the budget will define it faster than an hour of coding.

Write the limit down somewhere you will see it. This sounds like a small thing. It is the difference between a constraint and a preference.

What to do when you hit the wall

You will, and reliably around two-thirds of the way in. The instinct is to raise the limit. Before you do, try these in order:

Cut a feature. Not shrink — cut. Constrained projects almost always contain one feature that was never the point, added because it seemed like something the thing should have.

Change the shape of the problem. If the code is fighting the limit, the limit may be telling you the approach is wrong. The tightest solutions usually come from noticing that a different framing makes half the code unnecessary.

Ship the smaller version. Whatever runs inside the budget is the project. The version that needed more room was a different project, and you can write it another day.

Then, if none of that works, raise the limit and note that you did. There is no scoring here. But knowing you went from four kilobytes to six, and why, is more interesting than pretending the number was always six.

The part that is easy to miss

The four-kilobyte suggestion sits on a page about a person who wrote a web framework in four kilobytes, a GUI toolkit for beginners, and a programming book with cartoon foxes in it. None of those were constrained because constraints are a productivity technique.

They were constrained because a very small thing that works is funny, and delightful, and slightly unreasonable — which is the same argument as putting the best practices away, and making something delightful and slightly unreasonable is the entire point of the day. The limit is not there to make you efficient. It is there to make the result surprising — including to you.

The short version