The resurgence of a retro‑sounding metric

When Matt Sephton published the Fits on a Floppy manifesto, the phrase sounded like a nostalgic joke. Yet the core idea—keep software small enough that every byte matters—has become a touchstone for a growing segment of the community that values understandability over feature overload.

Evidence of a movement

• Concrete demos – Sephton’s 18 tiny utilities, each under 1 MB, are hosted on GitHub here. The accompanying screensaver nods to the classic Berkeley Flying Toasters, showing that playfulness can coexist with restraint.
• Modern projects embracing the constraint – The Dillo browser team handed out actual floppy disks at FOSDEM 2025, each containing the full release. Drew DeVault has announced that the upcoming 1.0 version of his Hare language will be sold on a 3.5‑inch floppy, a promise documented on the Hare website.
• Janet Language – Although its binary is just over 2 MB, it still fits on the 2.8 MB floppies used by late‑model IBM PS/2 machines. The maintainers highlight the size in their download page.
• Container footprints – The Trifecta image‑sharing demo ships as a 1.7 MB compressed Docker layer. With a few tweaks, it could be squeezed onto a 1.4 MB floppy, proving that containerisation does not have to imply megabyte‑scale bloat.

These examples illustrate a pattern: developers deliberately impose an artificial ceiling to force themselves to ask “Is this feature essential?” The result is code that is easier to audit, faster to compile, and cheaper to ship.

Counter‑perspectives

Not everyone agrees that a strict size cap is the right metric for modern software.

1. Complexity hidden behind small binaries – A tiny executable can still depend on large external libraries loaded at runtime. Critics argue that measuring only the compressed artifact ignores the broader dependency graph.
2. Performance trade‑offs – Optimising for size sometimes means sacrificing runtime speed or memory efficiency. In high‑throughput services, a few extra kilobytes may be a worthwhile price for lower latency.
3. Ecosystem fragmentation – When each project pursues its own minimal footprint, integration can become harder. Teams may need to write adapters to bridge a collection of ultra‑small tools, re‑introducing the very overhead the movement tries to avoid.
4. Security considerations – Minimalist code can be more auditable, but a small binary does not guarantee the absence of vulnerabilities. Regular updates and a robust supply‑chain process remain essential, regardless of size.

A balanced view

The manifesto’s strength lies in its reminder that constraints spark creativity. By setting a clear, low ceiling, developers are forced to strip away cruft, improve documentation, and focus on core value. At the same time, the community should treat “fits on a floppy” as a heuristic, not a hard rule.

A practical approach could be:

• Start with a size target – Use the floppy benchmark as an initial goal during prototyping.
• Measure the whole system – Track transitive dependencies, runtime memory, and network usage alongside binary size.
• Iterate – If a feature pushes the project beyond the limit, evaluate whether it delivers proportional benefit.
• Maintain security hygiene – Apply automated scanning and regular patching, regardless of how small the code base becomes.

Looking ahead

As cloud providers continue to charge per gigabyte of storage and per CPU cycle, the economic incentive for lean software grows. At the same time, AI‑assisted code generation tools are making it easier to produce large, feature‑rich applications with minimal effort, potentially encouraging the opposite trend.

The tension between these forces suggests that the “fits on a floppy” mindset will remain relevant as a cultural counter‑balance. It may not dictate every design decision, but it offers a useful lens through which to evaluate bloat, maintainability, and long‑term stewardship.

---

If you want to try the manifesto yourself, the full text is available on the project’s GitHub page.