tl;dr The author [0] describes a simple ticketing system that his very busy coworker, Peter Högfeldt, created in 1986. Basically, it checked in numbered files to their version control (CVS, at the time) that could produce reports with grep. This system's simplicity lead to its longevity, as people could learn it easily and trust that its bugs had been ironed out long ago. This is in contrast to some OS software that tries to be everything to everyone and changes all the time [1].

[0] https://en.wikipedia.org/wiki/Joe_Armstrong_(programmer) Joe Armstrong, of Erlang fame, so his blog posts have been discussed in the past.

[1] https://ntdotdev.wordpress.com/2023/01/01/state-of-the-windo...

I find this a helpful example. When I've heard the unix philosophy in the past, I didn't feel super convinced. Like, sure tar can do one thing, because it is a library (ignore that it can use gzip). But, where do you draw the line with a program like gnucash (financial tracking software) ? The core of the domain will involve keeping a ledger of transactions and converting them to relevant units. But, typing credit card charges in by hand is tedious [2], the kind of tedious that a computer should be good at. I would much rather that the program connect to my bank [3], to get the transactions directly.

[2] https://utcc.utoronto.ca/~cks/space/blog/sysadmin/Inventorie...

[3] https://beanhub.io/blog/2024/06/24/introduction-of-beanhub-c...

Minimal Viable Programs (2014)