
Minimal Viable Programs (2014) - exupero
http://joearms.github.io/2014/06/25/minimal-viable-program.html
======
lotyrin
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.

~~~
angersock
_Unix wasn 't enough, now we have Docker, etc._

We have Docker et al. because people kept pursuing ever-more-complex and ever-
more-intertwined dependencies and silliness.

The people failed Unix (and its successor, Plan 9), and not the other way
around.

~~~
lotyrin
It's mutual. Unix didn't solve problems for developers of large systems that
stand on the shoulders of open source software libraries by failing to provide
dependency resolution or versioning + namespacing source/built files. (An
obvious [non-]decision given the timeline of its inception and intended usage,
but a failure nonetheless.)

So then we got some of the former with system package managers designed for
system administrators and some of the latter with version control/build
systems/dependency tools designed by and for software developers, but they
don't meet in the middle.

Docker is mostly used to just bridge the gap and force the system package
manager to be a per-app-namespaced dependency/build support tool.

~~~
loup-vaillant
> _Unix didn 't solve problems for developers of large systems_

That's a big problem right there. Why are systems large in the first place?
[http://vpri.org/](http://vpri.org/) already showed we can do smaller —likely
by 2 to 4 orders of magnitude. Solving the problems of large systems will only
mitigate the symptoms. The root cause is size. We should solve that instead.

Why solve problems you can bypass?

~~~
lotyrin
Sometimes problems really are just large. Sometimes you need results faster
than a single microcomputer's CPU(s) can produce them and UNIX was invented
too early to come with solutions for doing that in ways that prevent
complexity. HPC is paying the price.

We're fixing it (efforts like Kubernetes, Hadoop, Mesos), but it's tough and
we have a long way to go.

------
stabilo
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?

------
demands
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.

~~~
restalis
It's so amusing that is almost sad - I know such people around me, they get
constantly abused by their peers, don't have the necessary means to deliver
great results and get systematically bashed for that. So their situation is
not so much for their skills as for their weakness (of character).

------
zvrba
> 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.

~~~
restalis
"you can encapsulate small and beautiful programs into classes, and connect
objects at runtime to solve more complex problems"

Then in order to ease the integration between those classes you start
reshaping them a little bit (adding things that "would not be essential") and
thus they are gaining in this regard something very similar to the same
features that we were talking about.

