These were some of the topics discussed at the meeting of 20/02/2003

  • Have you used metrics and analysis tools? If so, which ones?
  • What would you want to measure? What would you want to do with the information?
  • How do you 'sell' refactoring?
    1. My approach: don't sell, just do it. Incrementally, in those spots where you need it (new feature, bug fix...) -- PascalVanCauwenberghe
  • Who pays for the required effort?
    1. Rather than asking "who pays for" I'd ask "who benefits from". Who pays when feature after feature is being hacked in and the design degrades week after week ? Who benefits from source code that is clean and readable ? --SvenGorts
  • Is it always sensible to refactor? Aren't you better of rewriting?
    1. Mistakes can be repeated. A rewrite could introduce new bugs, new problems, ...
    2. Refactoring can be expensive. Refactoring could be to expensive, especially in the absence of unit tests.
    3. Costs vs benefits risk. For a rewrite the costs can at best be estimated and the benefits are yet-to-be-proven whereas for refactoring both the costs and the benefits can be measured week by week. -- SvenGorts
  • The economics of rewrite vs refactor
    1. A rewrite takes time, until there is sufficient functionality. You can't sell during that time -- PascalVanCauwenberghe
    2. You can charge anew for a rewrite, maybe that's worth more than the maintenance fee you get for refactored code? -- PascalVanCauwenberghe
  • Can you refactor incrementally? Always?
    1. I believe so. In the last 3 years I haven't encountered any situation where I couldn't refactor incrementally. I think I know how to incrementally refactor the stuff I did the 7 years before that -- PascalVanCauwenberghe
  • Do large cleanup refactorings make sense ? Why or why not ?
Some people advocated the idea to have small refactoring cycles scheduled between the subsequent iterations. Major concerns with this approach where:

    1. What to refactor ? Refactoring the entire code base is impractical which begs the question "What to refactor?". Obviously we 'd like to refactor where it'll help us the most to implement the future requirements.
    2. Will you refactor ? By itself refactoring doesn't generate any business value, hence management is likely to cut on the edge of the refactoring cycles.
Related pages: XpBeMeeting20022003