Update of "On Worse is Better"

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.


Artifact ID: 0ccc458a02e367c0222f6c53ce1c79d30d97fa5fb3eb8fbce515d41be95c4609
Page Name:On Worse is Better
Date: 2019-01-04 06:49:45
Original User: kc5tja

Recently on the Mastodon network, 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 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 Ritche or Ken Thompson did 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.