Minimal viable programs: a 1980s ticket tool that refuses to grow up

Small, beautiful, essential

In a 2014 essay, Joe Armstrong revisited a simple idea: some programs should do one thing, and do it impeccably. A "minimal viable program" is the smallest program that solves a particular problem — no frills, no extras, just the essential. The concept feels almost quaint in an era that worships features and quarterly growth metrics. But Armstrong insists such tiny, focused tools can be more dependable and longer-lived than any feature-laden monster.

The Erlang ticket system — simplicity that stuck

It has been reported that the Erlang project's original ticket system, built by Peter Högfeldt in the mid-1980s, embodied that ethos. Allegedly, Högfeldt knocked together the system in a couple of hours: one shell command, newticket, returned an integer and created a file in a tickets directory that was also checked into CVS. No dates embedded in the ticket; revision control handled timestamps. The result was a tool so lean it became part of the team's workflow for decades — workhorse reliability, no glitter.

Features vs. longevity

Armstrong's point is blunt: adding features is often good for sales, bad for users. New features mean new code, new bugs, and a creeping incompatibility tax. Do we always need another checkbox or dropdown? Sometimes what we need is a program that will do exactly the same thing a hundred years from now as it does today. Dropbox and Twitter get a shout-out in the essay as modern examples of focused design — they do one or two things, and they do them well.

Why this still matters

The larger argument is structural: when you assemble complex systems from components, each added feature adds upward pressure on the whole. If the building blocks are minimal, the system stays manageable. That’s the emotional beat here — admiration for tools that just work, and a gentle dare to the industry: trim the fat, and maybe we won’t be buried under our own cleverness. Who wouldn’t want software that ages like fine hardware: predictable, useful, and annoyingly reliable?

Sources: joearms.github.io, Hacker News