Refactoring's Original Sin: Part I


Before there was Refactoring there was refactoring. There were people who refactored just fine before Refactoring was invented.

I remember right well.

I remember back during the late 1980s, the OOPSLA-era Object boom was in full bloom. I had joined a new research group led by Ralph Johnson at the University of Illinois at Urbana-Champaign. And some of us were availing ourselves of the privilege of getting the best apprenticeship in object-oriented programming a body could ever get: spelunking around the PARC Smalltalk-80 codebase.

Gauguin and Tahiti

Here we found code that had clearly been crafted by insanely bright, committed pioneers who had stuck with it, lived amongst it, inhabited it, as they acknowledged themselves, polished it and cultivated it. And incrementally improved it. It was clear to anyone who visited the place, and it felt like a place, that the kind of code you were browsing was the fruit of a patient, sustained, collaborative process of cultivation. All the code was there. You were free to roam, and explore as you pleased.

It was a place that enticed you to join it. Smalltalk development enticed one to "go native", like Gauguin's Tahiti. And you grew and cultivated your code next to theirs, and when you saw an opportunity to improve it, you did. And your code grew better too.

Of course, even then, during the dusk of the Cold War, not every working programmer left every first draft untouched. If you were overconscientious, you might routinely do this as part-and parcel of bringing an implementation into being. Sometimes these ideas would come into focus once the code was actually on-the-air. In those days, when you wanted to improve the design of a chunk of existing code, you said you were going to clean it up, or take a final polish pass over it, or maybe tidy it up a bit. An enlightened boss might tolerate such an indulgence at the end of a successful push. But even then, the suspicion that you might be engaging in self-indulgent lily-gilding was never far behind.

Often, your focus would be strictly on improving the code's clarity or structure, or aesthetics without changing the way it worked at all. By analogy with number theory, one could casual describe a reworked or improved version as being better factored than its predecessor. It became natural to describe the newer take as a refactored version of the older one, and more broadly, to describe this kind of focused improvement activity as refactoring. Still, this most often was less a distinct phase that an acute, opportunistic shift of focus. It was typically part of preparing the groundwork for some subsequent functional improvement.

And so it came to pass that in the early days of the reign of George Bush the Elder, Bill Opdyke and Ralph Johnson set about the task of cataloging some of these Things You Could Do to Programs that Didn't Change The Way They Worked But Made them Better, with an eye towards seeming studying them more formally, and seeing whether they could be automated. And refactoring became Refactoring, with a Capital-R.

A Refactoring became a much more narrowly cast behavior-preserving program transformation, which served their research agenda fine, but cast the broader, more casual usage to the side. Refactoring, the activity, had henceforth to be one in which only such sorts of transformation were to applied. A distinct activity.

Subsequent authors, such as Martin Fowler (Refactoring) and Joshua Kerievsky (Refactoring to Patterns), have probably inadvertently reinforced this impression with their detailed focus on the surgical tactics and skills required to accomplish particular Refactorings, at times seemingly at the expense of broader, more holistic therapeutic approaches to day-to-day codebase health maintenance.

Adam and Eve So, what was Refactoring's Original Sin? Letting the idea be framed as a distinct phase, a polishing pass, an optional brush up, where working code was turned into "higher quality" working code that worked the same way as the original working code. Framed this way, this could sound like an utterly optional spasm of indulgent, flamboyant, narcissistic navel gazing by self-indulgent prima-dona programmers, rather than a inherent, indispensable, vital element of a process that cultivated the growth and sustained health of both the codebase and the team.

The problem with "refactoring" is that refactoring is not a bad name for Refactoring proper, but that the idea has always cast a wider shadow, in part because of its gestation in precisely the kinds of iterative incremental incubators we nostalgically recalled above.

As a result of having framed in this fashion, the perception persist to this day that refactoring is a distinct, coarse-grained, and dispensable luxury, rather than a natural, inherent, integral part of a healthy, sustainable development process.

The problem is that the refactoring process in which Refactoring plays this indispensable role, and the value of the resulting code, have never been really properly framed.

And a consequence of this is that refactoring itself becomes a casualty in precisely the kinds of TradableQualityHypothesis triage games that the Martin Fowler piece that triggered this one so eloquently showcased.

About this Entry

This page contains a single entry by Brian Foote published on February 23, 2011 7:46 PM.

Presidents Day 2011 was the previous entry in this blog.

Kakonomics is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.


November 2012

Sun Mon Tue Wed Thu Fri Sat
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  

Brian's Links



Brian Marick
Martin Fowler
Ralph Johnson (That's Completely Bogus!)
Dave Thomas (The Pragmatist)
Glenn Vanderberg
Patrick Logan
Lambda the Ultimate
Joshua Allen (Better Living Through Software)
Mariann Unterluggauer (Motz)
James O. Coplien
Eugene Wallingford
Blaine Buxton
Nickieben Bourbaki
Travis Griggs
Ivan Moore
Mike Mikinkovich
Superboy & Ward
Rebecca Wirfs-Brock
Nat Pryce
Tim Ottinger
Forrest Chang
Gregor Hohpe
Sam Gentile
Robert Hanson
Chad Fowler
Jonathan Edwards
James Robertson
Bruce Eckel
Andrew Stopford
Tully Monster
Grady Booch
Dave's Ramblings
Solveig Haugland
Dave Hoover
But Uncle Bob
Doug Schaefer
Ted Leung
The Farm
Ian Clysdale (Random)
Gilad Bracha
Keith Devens
Urbana-Champaign Techophiles
Stefan Lauterer (Tinytalk)
Planet Python
Chris Koenig
Peter Lindberg (Tesugen)
Jason Yip
Sean McGrath
Jeff Erickson (Ernie's 3D Pancakes)
Steve Freeman (Mock Turtle Soup)
hakank (komplexitetemergens)
Deciduous Ponderings
Take One Onion
Ken Schreiner
Michael Mahemoff (Software as She's Developed)
Champaign Media Watch
Jason E. Sweat's Weblog (PHP, etc.)
Raymond Lewallen (Code Better)
Keith Ray
Raymond Chen (The Old New Thing)
Neil Gafter
Joe Walnes
Ivan Moore
LD/dazza (Lost in La Manche)
Scott Rosenberg (Wordyard)
Dave Stagner (Sit down and shut up!)
Walter Korman (Lemurware)
Munawar Hafiz (The space between)
Rafael de F. Ferreira (Rafael Rambling)
Mike Hostetler (Where Are The Wise Men)
Jordan Magazine
Andriy Solovey (Software Creation)
Mike Griffiths (Ideas and essays on code development)
Ashish Shiraj (Ashish Kumar -- Software Test Engineer)
Nathaniel T. Schutta (Just a thought...)
Lynn Cherny (Ghostweather R&D Blog)
Dominique Boucher (The Scheme Way)

Powered by Movable Type 5.14-en