Minimal Viable Programs (2014)

One‑command bug tracker has fans swooning, skeptics side‑eyeing

TLDR: A 1986 one‑command bug tracker stored each issue as a simple text file and relied on version control for history. Comments split between celebrating its no‑frills reliability and calling out the hidden complexity under the hood, with cross‑industry envy and a nod to Joe Armstrong’s legacy fueling the debate.

A decades‑old tale just set today’s comment section on fire: in 1986, a busy engineer whipped up a one‑command ticket system—type “newticket,” get a number, and a plain text file becomes your bug report. No timestamps in the file? Who cares—version control already remembers them. Want stats? A quick text search counts open issues. Minimal. Durable. Kinda beautiful.

Cue the split. Minimalism romantics cheered that simplicity = trust, echoing that this tiny tool survived because anyone could learn it and nothing changed out from under them. One fan wished their construction job had something this straightforward. But the snark squad arrived with a magnifying glass: “Which part is ‘minimal’ if you’re standing on an entire mountain of operating system, shell, and version control?” Translation: even simple tools stand on complex stacks. Hot take city.

There was a nostalgic, tender moment too: a commenter noted it’s Joe Armstrong’s death anniversary, turning the thread into a mini‑tribute to the Erlang co‑creator whose name appears in the example. Meanwhile, folks turned the line “give the busiest person the job” into a meme, imagining managers shouting “Find the busiest dev!” while hurling tickets. In classic internet fashion, the crowd is torn between “less is more” and “less is hiding more”—and everyone’s having a great time arguing about it.

Key Points

  • A Minimal Viable Program (MVP) is defined as the smallest complete solution with no nonessential features; removing any feature breaks it.
  • The Erlang ticket system, created by Peter Högfeldt (stated as implemented in 1986), used a single command to generate a numbered ticket file in the user’s home directory.
  • Tickets were plain files with fields (ticket, responsible, status, title) checked into a shared CVS repository; timestamps came from version control metadata.
  • Reporting was achieved via simple shell scripts using standard tools like grep and wc; rules limited status to open/closed and required consent to reassign responsibility.
  • The article argues against feature creep due to complexity and instability, advocating MVP-based components; cites Dropbox and Twitter as examples of focused design and notes Photoshop as a complex counterexample.

Hottest takes

"I wish the construction industry had a standardized issue reporting system like this" — smalltorch
"simplicity led to its longevity" — Nzen
"which part is the minimal ticketing system?" — jodrellblank
Made with <3 by @siedrix and @shesho from CDMX. Powered by Forge&Hive.