Here’s my notes from the four hour workshop by Michael Feathers on Brutal Refactoring. I’m trading off timely information for something that probably could be more succinct or polished with a bit more time.

Michael opened with the discussion on what is Clean Code versus Understandable Code, and why each is important. He makes the point, using some good examples from different languages, we can live with understandable code, and there is a cost to having Clean Code, particularly when you have it. He explained it through good relationship with Behavioural Economics, taking about how the incentives for people maybe aren’t quite set up right.

He asked a question, “Is it easier for people to add code to existing place than to create a new method/class/etc? Why?” It’s a good analogy, and something that you even seasoned, diligent programmers often fall foul when working in small increments.

There were some further good discussions about “Understandable” being contextual. Such as, a C++ macro might seem “magic” to non C++ users, but could be quite familiar. This remind me of the learning curve, my former colleague Dan North is going through with Rails at the moment. A nice reflection on some messages I talk about in my “Beginner’s Mind” talk.

Anyway, back to the tutorial. Feathers says, “We should’t be surprised by very large methods. incentives are set up wrongly. Though not sure what we can do about it.” He further acknowledged it wasn’t a “bad coder’s” action, but a systemic effect, “It’s the result of the system between us and the code.” I think this is quite important to note because I think the social system that software development occurs in is important as to what code you get up. For example, when you build teams, having an agreed code standard and consistent technical direction is essential into setting up a different system that incentivises different behaviour. If you know you’ll need to come back to something, and change it, you’ll want to leave it in a good state. If you want the respect of your peers, you’ll want to leave it in a good state.

Feathers then talked about some great visualisations he’s been working on. He’d get on great with many of my colleagues, particularly Erik Dörnenburg who loves to champion this sort of stuff. I agree when Feathers says, “Code has a particular shape,” when you’re looking at a particular system.

Feathers than covered a good deal of stuff as shown in the Mind Map. I have some rough notes.

Feature Clustering

  • Listing out features and looking for commonality. Sometimes you look for common arguments across classes/methods. Sometimes it’s about common data (Data Clumps as Fowler talks about in his book).
  • Look for Locality of information (or encapsulation in OO talk)

Rapid Scratch Refactoring

  • A bit of regret not focusing more of it in his book.
  • You learn a lot my attempting stuff out and then seeing, “What could be?”
  • Some discussions on the danger of making these too much of a big leap and never reaching for it. (Just another reinforcement about clear vision and essential leadership to keep people heading in the right direction”
  • I found it interesting he liked to do it in a plain text editor instead of an IDE. Feathers talked about the distractions of syntax highlighting. I find that I learn a lot more information (and can try things out faster with an IDE like IntelliJ or Resharper)

Twisting Classes

  • Breaking down a class based on use rather than adding more
  • Step by step process of creating a new role (via interface or superclass and using that in a consumer rather than the original)
  • Feathers recommends a very riguourous command query separation

There’s lots of other small gems included. Some notable tweets worth saving:

  • “Branches often biggest impediment to refactoring in large orgs.”
  • “Narrowing scopes: often we gain leverage by moving temporary variables coser to their points of first use”