Worse Is Better

Progress, not perfection

Mike Sherov

Principal Worst Engineer

Core UX @ Skillshare

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[...] improve it to 90% of the right thing.

Zen

Overview

• History: New Jersey vs. MIT
• Characteristics of Design
• Why Worse is Better
• YAGNI - You Ain't Gonna Need It
• Big Rewrites

History

NJ Approach

MIT Approach

• C
• Unix
• jQuery
• Javascript

• Lisp
• CLOS
• Dojo
• Python

Richard P. Gabriel

http://www.dreamsongs.com/RiseOfWorseIsBetter.html

Characteristics of Design

Simplicity

New Jersey: must be simple. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.

MIT:  must be simple. It is more important for the interface to be simple than the implementation.

Characteristics of Design

Correctness

New Jersey: must be correct in all observable aspects. It is slightly better to be simple than correct.

MIT:  must be correct in all observable aspects. Incorrectness is simply not allowed.

Characteristics of Design

Correctness

New Jersey: must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency.

MIT: must not be inconsistent. A design is allowed to be slightly less simple and less complete to avoid inconsistency. Consistency is as important as correctness.

Characteristics of Design

Completeness

New Jersey: must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must be sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.

MIT: must cover as many important situations as is practical. All reasonably expected cases must be covered. Simplicity is not allowed to overly reduce completeness.

Characteristics of Design

*Consistency can be sacrificed to achieve completeness if simplicity is retained

Why Worse Is Better

The PC Loser-ing Problem

• MIT: "The Right Thing" is to back out and restore the user program PC to the instruction that invoked the system routine.
• NJ: Meh. That's too complicated. Throw an error. Programmers will catch it. Let's keep Unix simple.
• MIT: Unix itself is simple, but catching errors is a complex interface.
• NJ: Meh. Implementation simplicity over Interface simplicity.

Doing "The Right Thing" was too complex.

Why Worse Is Better

Viruses That Reproduce, Spread

• Unix was "good enough". People wanted to port it.
• Unix was simple. It was easier to port than CLOS.
• C was designed to write Unix, therefore people wrote C and C Compilers to port Unix.

Why Worse Is Better

Distribution Attracts Attention

• Unix was everywhere. It's about 50% of what's needed though. Lots of folks to get it to 90%
• Going from 50% to 90% represents huge wins for users with low expectations.

Why Worse Is Better

The Virtuous Cycle

Release

Adopt

Improve

YAGNI

You Ain't Gonna Need It

Always implement things when you actually need them, never when you just foresee that you need them.

Do the simplest thing that could possibly work.

Simplicity - the art of maximizing the amount  of work not done - is essential.

YAGNI

You Ain't Gonna Need It

Must be used with continuous refactoring, continuous automated unit testing, and continuous integration.

YAGNI

You Ain't Gonna Need It

Avoid Premature Abstraction (Rule of Three) and Premature Optimization (Knuth's Root of All Evil)

Big Rewrites

There is a lot of FUD about wholesale rewrites. Many will tell you to simply not do it. But why?

• Things You Should Never Do
• Rewrites Considered Harmful?

Fear. Uncertainty. Doubt.

Big Rewrites

Chad Fowler lays out the reasons why Big Rewrites may fail, and in doing so gives us hope.

• The Big Rewrite

The Light

Big Rewrites

It is hard to discover what the existing system does. Reading code is harder than writing it.

Software as Spec

Big Rewrites

Tempting to "fix a bunch of bugs" or "add a few features" to the rewrite. Tweaks turn into reinvention without normal product dev checks and balances.

The Wish List

Big Rewrites

Should we deliver the Rewrite incrementally or all in one big release? One big release wins the argument. The old system needs patches that don't get forward ported, etc.

The Big Bang

Big Rewrites

Rewriting a working application always has to come with why? "More maintainable", "better dev velocity" are unmeasurable notions. Newer promises are added on: "Better Uptime" "Performance". Everything gets attributed to the new system, regardless of the truth of the statement.

Justifications

Big Rewrites

The domain experts are "stuck" tending to the "old" application, while technology experts implement the "new" system, which will yield missing pieces of the domain, or at least cost more communication than expected!

Who's Tending the Store?

Big Rewrites

So What Can We Do?

What are the lessons from Worse Is Better that can help with a big rewrite? Can you turn a big rewrite into something else?

Big Rewrites

So What Can We Do?

• Deliver worse slices faster.
• Spread them wide.
• Improve them together.

What Questions Do You Have?