Red, Green, Premature Refactor

"Red, green, refactor" promotes premature abstraction.

I had all the information to come to this conclusion 20 years ago. I'm embarrassed to admit how long it actually took.

What makes me say that? Well, sometime between 2003 and 2005, I met Ward Cunningham at a Seattle Extreme Programming Users Group meeting. There was no presentation that night. Rather, we just sat around eating pizza and peppering Ward with questions. His answer to one question really stuck with me.

The question was, "How do you convince management to let you refactor code?"
Ward answered, "I don't," then paused for effect, and continued, "I give them two estimates: I say, it'll take this long to make room for the feature, then it'll take that long to add the feature."

So Ward was saying that he refactors before beginning to work on a new user story. He was essentially advocating for what Mary and Tom Poppendieck referred to as "the last responsible moment." As in, don't make a decision until the last responsible moment.

Some-teen years later, it dawned on me that these three things are not separate. That is, if you refactor when you finish a feature, you're likely trying to predict how the software will change next. Or worse, you're trying to predict how the software will eventually change.

So, my new mantra, which needs a stickier name, is: "pick up a story, optionally do a structural refactor, write a failing test, make it pass, optionally tidy up, then commit and push."

I no longer do structural refactoring at the end of a user story. Though I might do some small, tidying refactors. This allows me to wait until the last responsible moment — after I pick up the next related user story — to choose an abstraction.

Give it a try. Let me know how it goes.