Ken Mayer
Ranked 60 in Phase 1 with 44 unique views, 13 counted upvotes and 12 counted downvotes

Crossing the Refactoring Swamp


Refactoring can be hard to balance against the urge to dive right back into delivering features. The good news, though, is that refactoring can take place anywhere. It can be done solo. It can be done in pieces. Recently, when I needed to refactor an annoying patch of code, I worked on it during my daily commute to and from the office. It didn’t interfere with client work or family time, and I accomplished a significant amount of work with near-zero opportunity cost.

Additional Notes

Red-Green-Refactor Without Refactor Is About As Useful As a Two-Legged Stool

The test-driven development “mantra” is red ➔ green ➔ refactor ⟲. It is an essential step in the development process. Without it, over time, your code will accumulate unnecessary dependencies, have poor separation of responsibilities, and present confusing interfaces; all the opposite of SOLID design.

Technical Debt Is Like a Payday Loan

It is quite easy to be seduced to the dark side where you get to “green” and then decide to refactor “later,” where later often never comes. This decision is like a payday loan. You are incurring technical debt every time you deliver a new feature. And as is true for payday loans, your velocity will appear to be faster, but just a few iterations down the road, the debt must be paid. Eventually, your velocity will start to bog down, developers will cringe when they have to edit the code, tests will become brittle, and finally, refactoring will no longer be an option. The only choice will be to declare “bankruptcy”; that is, rewrite the code from scratch. That is why it is so important to complete the refactor within the context of a feature.

Previous Next


  • The proposal author responded 8 months ago

    50% of my talk focuses on why's instead of the how's. That's what will make it different from YART:

    I talk about the real-world pressures to skip the refactoring pass. Why that's a terrible thing to do. It distorts velocity instead of enhancing it.

    I also explore where you might want to skip refactoring, where incurring technical debt is the more pragmatic choice. In the real world you need to be able to make that assessment.

    Finally, but this is where I got the idea in the first place, sometimes you inherit of pile of crap and you need to fix it to get the system to do something [else/better/more]. How do you get it done within the "usual business day" when there's so much pressure to keep delivering stories? Perhaps the PM won't give it high enough priority. Here's where the "you find extra time where you can" comes in. I certainly wouldn't advocate making an already long day, longer, as a general practice!

    The title and abstract are slowly getting out of date as I do rewrites (I'm starting another pass after I write this response). It's becoming a contrapuntal in five movements. The baseline melody is the "usual refactoring talk" which I counter point with business and process arguments.

  • 5976001c9ebf095c4988855a4e102de5?d=retro Clemens Kofler suggested 8 months ago

    To me, this reads like Yet Another Refactoring Talk that have been omnipresent at (Ruby) conferences over the past few years. What will make this talk different from all the other talks at all the other (Ruby) conferences around the world?

    Moreover, there's a small thing that I find quite disconcerting: You write about how you did refactoring on your daily commute without interfering with client work or family time. While I would certainly never suggest to work on a 9-to-5 schedule, in my mind this sends the wrong signal: Clients and employers should be educated to see actual business value in refactoring if they're not seeing it already.

    That being said, let me state my suggestion again: Please outline what would make your refactoring talk different from all the other refactoring talks. If it really will be different, I might give it a +1.

  • The proposal author responded 8 months ago

    All my examples are from open source ruby project that I maintain. The repository is on

    I want to tell a "war-story" about the refactor. The story is the device to deliver several themes:

    • Refactoring is a skill that must learned and practiced, daily.
    • Refactoring is hard. It isn't the reward or the cherry on the cake for delivering a feature.
    • Technical debt has real-world consequences that upper managers often miss.
    • As developers we should not skip the refactor pass ("later" when later never comes).
    • And yet, there a times when you should not spend time on refactoring; this must be a conscious choice with full knowledge of the costs and benefits.
  • D87dddeb300217e6c6574f5ffae220be?d=retro Nikos Dimitrakopoulos suggested 8 months ago

    Technical dept and refactoring is usually a daily conversation topic especially when trying to go faster and something drags you down. Are you planning to propose something specific in order to improve this situation, or just the same old rules of test and refactor before saying it's done? Also, is it going to be generic for software development or is it going to have a more ruby flavour?