My Adventures in Coding

March 15, 2008

Refactoring to Patterns – Summary

Filed under: Refactoring — Brian @ 11:29 pm

While attending Joshua Kerievsky’s talk at SD WEST he went into a brief overview of a number of refactoring patterns. If you want to read about these patterns in detail (and you should!), you should get a copy of the book Refactoring to Patterns. However, to help peak your interest on the subject, here is a quick overview of a few of the patterns discussed at the talk.

The Three Basic Strategies used in Refactoring

  • Extract method
  • Extract class
  • Move Method

Piecemeal Refactoring Pattern

  • Divid and Conquer
  • Split problem in half
  • Work at solving smaller problems

Narrowed Change Pattern

  • Extract methods to determine where the change needs to be
  • So refactor 3 methods, not 50
  • Change only that area, make the change isolated to only a few places
  • Narrow the change down to a smaller number of change points

Gradual Cutover Refactoring

  • Move from A to B gradually
  • Start with 1,2,3 to 30
  • So the idea is you can ship to production with 10 of 30 pieces of code switched over while in a releasable state the entire time
  • This type of refactoring can be done along side other work without affecting the release schedule for other development work

Parallel Refactoring

  • Write the refactored code along side of the existing code
    • THEN decide later on how and when to finally cut over to the new code
  • This is a very conservative safe approach to refactoring.
  • It also gives management the ability to make the decision whether or not to cut over to the new code in a release
  • So if it is not tested properly by the time of the release, just don’t switch over, no need to roleback changes or take any other steps

Refactoring – Convincing Managers

Filed under: Refactoring,SD West 2008 — Brian @ 11:14 pm

While at SD WEST I was lucky enough to attend a talk by Joshua Kerievsky on refactoring. The following is just a summary of my notes from the talk.

The 5 stages of a software company (They all make the same mistakes)

  • V1.0 – Developers are happy. The team can develop software quickly. No legacy code to read or fix, no maintenance or scalability issues to deal with (yet). All work is on new features so managers see the value in all the work and are happy.
  • V2.0 – Still pumping out new features just as fast as in V1.0. Starting to notice some technical debt. However, at this point it is small enough to not slow development down or be that big of a concern.
  • V3.0 – More focus on just new features. Same focus as in V1.0 and V2.0. However, now the maintenance bugs are starting to flood in. Stability of the product is decreasing. Customers are getting frustrated. Management reacts by adding more support people and creates a team of maintenance developers.
  • V4.0 – The really great talent starts leaving the company out of frustration. Management starts to look at out sourcing for support and maintenance tasks as a solution.
  • V5.0 – Finally, managers call in experts to help fix the issue, which means a great deal of refactoring work. This is paying a great deal of interest on technical debt that could have been avoided if that debt was dealt with on a regular basis (like paying your credit card bill monthly, not once every year or two).

How to get Managers to Understand the Cost of Legacy Code

Explain it in terms of poorly written driving instructions:

  • You spend a lot of time reading the instructions trying to understand them, this is a waste of time
  • So you then try and ask other people if they understand the instructions, each having a different interpretation
  • Now you try and drive there, how many times do you get lost, how much longer does the drive take?
  • If only the instructions were clear and concise, imagine how much time could have been saved

Now imagine how hard it is for a new developer to understand an existing system that is in a similar state as these driving instructions. The root problem is many different styles from many different developers. As a result code gets more and more confusing over time. Continuous refactoring can help mitigate this problem. Refactoring is the ongoing process of making software simple and concise.

March 6, 2008

Recommended Refactoring Books

Filed under: Refactoring,SD West 2008 — Brian @ 8:21 pm
Tags: ,

During the talks I have attended this week there have been some books that have been mentioned over and over again.

So far the number one recommended book, and this has been recommended by presenters who also have published excellent books on design and refactoring has been:

“Working Effectively With Legacy Code” by Michael Feathers

Also, other books mentioned repeatedly have been:

“Refactoring: Improving the Design of Existing Code” by Martin Fowler, Kent Beck, John Brant, and William Opdyke

“Refactoring to Patterns” by Joshua Kerievsky

The Rubric Theme Blog at


Get every new post delivered to your Inbox.