Home > .NET, Extreme Programming, Test Driven Development > When Refactoring is YAGNI …

When Refactoring is YAGNI …

I attended a Washington DC XP UG (WDCXP) meeting tonight for the first time. It was a smallturnout with Bryant Smith presenting on DIP (Dependency Inversion Principle) with a slant to persuading new developers to adopt agile techniques through design patterns. The discussions were interesting and varied wildy across different aspects of design patterns and XP.

One question that has been bugging me with the project at one of my clients is the case for Refactoring. As TDD developers, we all know that Refactoring is essential to atone for the sins of DoingTheSimplestThing. But how do you reconcile the time spent refactoring with the features that the customer would have to give up for that time? I am not talking about the little ExtractMethod or IntroduceExplainingVariable here – those are quick and easy … I mean realizing a design pattern is now needed and implemented it. The refactoring tools are very limited in the .NET world at the moment – meaning that this refactoring will have to be done by hand and then tested (with your existing suite of tests, of course!). It is easier to just TODO the item and move on, especiallywhen under atime crunch. Thisaccumulates a burden of TechnicalDebt as the project runs its course. I wrote a little custom NAnt task a few months back to traverse our source code and put together a list of the all the TODO items – there are around 300!

Adam (a member of WDCXP) suggested two possible solutions:

  1. Force refactorings to be done before checking the code in
  2. Add needed refactorings when next a feature is added to that subsystem

Forcing the refactorings doesn’t solve the lost time forother features problem. I like the adding the refactorings as code is changed but I still feel a lot of those TODOs will be left undone. Maybe that is OK?

Please note that this system and associated project is highly successful and is loved by developers and users alike (despite the many remaining TODOs).

How do you reconcile your time refactoring against lost value to the customer?

UPDATE:More food for thought… RefactoringTrumpsYagni ?

  1. Darrell
    October 19, 2004 at 1:00 pm

    I usually explain to the customer that major refactoring (the kind you are talking about) allows for future changes at less cost. And these are usually given the OK unless we have a “have-to” meet deadline.

  2. Jeff Atwood
    October 21, 2004 at 5:52 am

    Right. Refactoring allows other features to be added. Without refactoring, the code becomes an unmaintainable mess over time. That’s like the old saying– there’s never time to do it right, but always time to do it over. False economy.

    Like taxes, refactoring is a basic cost of doing business (when programming). At least that’s how I think of it!

  3. http://
    October 21, 2004 at 11:37 am


    Unlike taxes, if you inadvertently forget to refactor, a government agency doesn’t come to your home, hold you up to ridicule, strip you of all but your most meager belongings, impose a process whereby you lose most of each paycheck and psychologically rape you until you have nothing left but the most tenuous link with sanity.

    But I agree that refactoring is a good idea.

    — Bob

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: