Atlas · Details
Transformation
AI Notes
Java programmers keep telling Steve they can't use Ruby because it lacks automatic refactoring tools — so Steve goes back and reads Martin Fowler's Refactoring closely. The book, Steve points out, is two halves: a catalogue of the everyday mistakes that produce smelly code (premature optimisation, intermediate-value local variables, oversized parameter lists, null-as-token, boolean thickets, bloated inheritance) followed by a menu of mechanical recoveries. The first half is design; the second half is recovery. The industry absorbed the recoveries into the IDE and quietly forgot the rest, which leaves a field that assumes bad code is inevitable and treats the tool as Productivity in a Bottle. The caterpillar/earth-mover metaphor that closes the essay is the working image — segmented machinery crawling across code that was written badly enough to need it.
The argument is about amnesia: the field kept the tools and dropped the lessons. Two years later Code's Worst Enemy sharpens the same point into a knife about codebase size; here it's still patient, still hoping the working programmer will go back and read the first six chapters.
Related listings
-
2005
Practicing Programming
Same year — the companion argument that working programmers don't practise the way every other craft practises. Transformation is the same point made through one book.
-
2004
Being the Averagest
A few months earlier. Being the Averagest names the problem — no metrics, no competition; Transformation gives one specific example of the way the field papers over the gap.
-
2007
Code's Worst Enemy
Two years on, with conversion complete. Transformation is the friendly reading; Code's Worst Enemy is the argument that the codebase itself is the problem the refactoring tools were quietly making worse.