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.
NJ Approach
MIT Approach
Richard P. Gabriel
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.
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.
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.
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.
New Jersey | MIT |
---|---|
Simple Implementation | Correct |
Simple Interface | Consistent |
Correct | Complete |
Consistent* | Simple Interface |
Complete* | Simple Implementation |
*Consistency can be sacrificed to achieve completeness if simplicity is retained
Doing "The Right Thing" was too complex.
Release
Adopt
Improve
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.
Must be used with continuous refactoring, continuous automated unit testing, and continuous integration.
Avoid Premature Abstraction (Rule of Three) and Premature Optimization (Knuth's Root of All Evil)
There is a lot of FUD about wholesale rewrites. Many will tell you to simply not do it. But why?
Chad Fowler lays out the reasons why Big Rewrites may fail, and in doing so gives us hope.
It is hard to discover what the existing system does. Reading code is harder than writing it.
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.
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.
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.
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!
What are the lessons from Worse Is Better that can help with a big rewrite? Can you turn a big rewrite into something else?