D 2019-01-04T06:52:02.616
L On\sWorse\sis\sBetter
N text/x-markdown
P 0ccc458a02e367c0222f6c53ce1c79d30d97fa5fb3eb8fbce515d41be95c4609
U kc5tja
W 3514
Recently on the Mastodon network, [@Elizafox@mst3k.interlinked.me](https://mastodon.social/@vertigo/101331345337548959) wrote the following:
> The state of the industry is not just that "worse is better," it's that "worse is way more preferable than better." People are encouraged to push things out the door more than they are encouraged to worry about the security aspects. Worse still, many programmers work at the very institutions that are actively working to undermine online security. Brilliant, bright minds, may I add. Some of the best in the business.
>
> Programmers are at war with each other, and there are no winners in civil war.
This is an amazingly insightful comment, which I'd like to expand upon.
"Worse is better" has never felt comfortable to me.
I get it: it's convenient, and it has delivered much value to others.
Yet, to mistake an **observation**
as a **core value**
to be possessed by software developers
is counter-productive, and inexorably leads to shit software.
"Worse is better"
is what *naturally* falls out of the process of prioritizing requirements;
of not achieving all of your ambitious goals *and being OK with it.*
**It's not meant to be taken as life advice.**
If you study
[Gabriel's original essay](https://www.dreamsongs.com/RiseOfWorseIsBetter.html)
that gives rise to the meme,
you'll find that it is a study of intense pragmatism.
It must be noted that
the four principles of the Gabriel's *right-way* and *worse-is-better* approaches
are mostly similar to each other.
Look at where they differ, however, and you'll see they're all rooted in economics.
The original Unix system is the way it is because of *economics*,
not because Dennis Ritchie or Ken Thompson didn't give a care about software quality.
It's *cheaper* to build minimal systems and
incrementally build on top of them
on an as-needed basis.
This is born out over and over again
throughout the history of project management and systems engineering.
Sometimes, though, you really do want perfection first.
If I'm to be put on a medical device to survive,
I *really* want the software to be built *the right way*.
Worse is better is not something I'd trust my life to.
Nor, I **hope**, would you.
Gabriel summarizes:
> The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing.
>
> A wrong lesson is to take the parable literally and to conclude that C is the right vehicle for AI software. The 50% solution has to be basically right, and in this case it isn’t.
Let that sink in.
Gabriel himself is telling us that the metaphor has limitations.
We should not take it so seriously.
Again, it's an *observation* on the state of software quality
as manifest between Unix and your typical Lisp Machine system software,
and on why Unix spread so widely while the latter stagnated.
If you succumb to the Worse Is Better *core value*,
you doom yourself to underachievement.
You set your goals too low.
It's better to have a good number of very lofty goals instead,
and prioritize those which you can actually achieve.
So, to summarize with my own sound-bite,
worse is better, but only in retrospect.
Try to do the right thing, and let economics and history determine how much worse the end result will actually be.
Z 30f4156a79c506a9b8fb515e56934518