The Wrong Abstraction

Sandi Metz · 20 Jan 2016 · sandimetz.com ↗

4 korrents from this piece

Sandi Metz did not write this page.

Every claim below was made in this piece, quoted word for word and numbered in the order the piece makes them, so you can read it there rather than take our word for it. The sentence above each quote is our reading of the claim, not their wording. Each quote was checked against a stored copy of the page at build time; where the two differ, the quote is the fact.

Our reading
Duplication is cheaper than the wrong abstraction, so code should not be made reusable before there are real examples of what the reuse has to do.

Their wordsduplication is far cheaper than the wrong abstraction

Interesting
Our reading
Existing code exerts a powerful influence: its presence argues that it is correct and necessary, and sunk cost keeps teams inside an abstraction that has stopped fitting.

Their wordsExisting code exerts a powerful influence. Its very presence argues that it is both correct and necessary.

Interesting
Our reading
Parameters and conditional branches accumulating inside shared code are the diagnostic that the abstraction is wrong.

Their wordsIf you find yourself passing parameters and adding conditional paths through shared code, the abstraction is incorrect.

Interesting
Our reading
When an abstraction turns out to be wrong, the fastest way forward is to inline it back into every caller and let the duplication show what the right one is.

Their wordsOnce an abstraction is proved wrong the best strategy is to re-introduce duplication and let it show you what's right.

Interesting