Minimal Viable Programs (2014)

Products should be made of programs. Programs should be able to be simple enough to be "complete" while how they get built, replaced, planned, and orchestrated however, is free to be as fluid as the problem to be solved.

Many systems tried to be this, but people too frequently side-step these solutions for decomposition because they aren't complete enough. Unix wasn't enough, now we have Docker, etc.

OOP tries to achieve this from a different level on the inside of complex systems, but still falls short. (e.g. you have to do IPC or have a message-passing VM where objects~=processes to be able to do live code replacement and allow multiple independently-developed implementations of the same concept to run simultaneously and collect behavior on which does a better job, so this type of thing is not common.)

It'd be nice if the progress towards building smaller systems that avoid complexity begins to outpace the progress toward building larger systems which defend against complexity within my lifetime, but I can't say I'm hopeful.

In reading comments of software authors in mailing lists and forums over the years, I sometimes noticed a particular vitriol for writing what are called "trivial" programs. By the same token, I sometimes noticed a strange attraction to large programs that only the author(s) could ever hope to understand. Not sure if I am the only one to notice this. I recall one author proudly telling a forum of programmers that his creation was so complex it would hurt the eyes of anyone who attempted to read the code.

I place the highest value on small programs and the lowest value on large, complex programs. But I suspect this is not the norm, whether among end users, authors, or both.

I also recall some comment from Kernighan about how back in the early days of AWK he was amazed at the sizes of the scripts people were writing. He had never expected AWK to be used to write large, complex "programs".

Maybe small programs are boring? Maybe people cannot manage to simplify their problems by subdividing them into smaller tasks? Maybe they do not believe the problems can be simpflied? Maybe adding features is how authors attempt attract or retain users? Who knows?

Amusing advice from this article:

> If you want a job done find the busiest person you know and give them an extra job. This is because the reason they are busy is that lots of people want them to do things because they are good at doing things and that’s why they are busy.

> A minimal viable program is the smallest program that solves a particular problem. It is small and beautiful. It has no additional features.

A problem is rarely well-defined. Alternately, you can encapsulate small and beautiful programs into classes, and connect objects at runtime to solve more complex problems. OO reinvented.

In his case, he prefers to use the shell to do the plumbing instead of another language.