Is the time spent refactoring a code base worth it in the long run, in terms of developer productivity?

It seems pretty clear to me that modifying a clean, well designed system is much simpler and faster than working on a poorly designed one, but I'm after some solid evidence. Are there any studies around this topic?

    – hakre
    Commented Jul 18, 2013 at 9:29
  • 1
    Start maintaining a mess yourself and be the judge. Commented Jul 18, 2013 at 11:33
  • Life experience confirms this. Unfortunately, the quick and dirty, copy-paste, programmer is often promoted ahead of the slow and quality oriented one. All (most) managers see is “develop time”. Don't try to explain maintainability to somebody who counts money. Commented Apr 19, 2022 at 14:47

2 Answers 2


Empirically, software with higher complexity metrics, such as cyclomatic complexity, are harder to maintain. There is research supporting this dating back to the 1970s ("Program Complexity and Programmer Productivity", E.T. Chen). There is also work that suggests that complexity density, which is cyclomatic complexity over size of the system also relates to maintenance time ("Cyclomatic complexity density and software maintenance productivity", G.K. Gill, C.F. Kemerer), which is also available for free here. Unfortunately, an IEEE subscription is necessary to Chen's paper, but you can try to look it up on other sources if you're interested.

From a quality perspective, it's often worth it to spend some time refactoring, assuming you have a test framework in place to prevent the introduction of new defects. This will allow you to more easily implement new features to your system, add additional tests, and train new developers to work.

Ultimately, however, there is the pressure to deliver new functionality and added value. You need to balance refactoring with the implementation of new functionality and repair of defects.

  • 2
    another point to add is that when you refactor, you also likely implement features in a better/more efficient/cleaner manner. There's an adage I've heard myriad times to the effect of "in 5 years you'll cringe that you thought your code was 'good'"
    – warren
    Commented Sep 15, 2011 at 6:49
  • 1
    @hakre I checked when I posted this and again now, using both a Google Web search and Google Scholar. At time I originally wrote this post, neither paper was available without purchase. However, since then, one paper has been posted on a University of Pittsburgh domain which appears to belong to one of the authors and I added a link to it. The other paper is not available for free. I did add the titles to the body of the post to make searching for them slightly easier. If you don't want to read the papers, you'll need to accept my analysis, coupled with my knowledge and experience.
    – Thomas Owens
    Commented Jul 18, 2013 at 10:23

I'm after some solid evidence

Then stop wasting your time here.

  1. Find some code that's expensive to maintain. It's easy. Look at your organization's trouble tickets.

  2. Find some code that's cheap to maintain. Find code that's run frequently, but has few or no trouble tickets.

  3. Measure the complexity with any of the widely available complexity tools.

  4. Bask in the evidence.

You have now provided numbers to confirm the obvious.

  • 6
    Not really. the complexity of the task performed by the software must be distinguished from the added complexity caused by the implementation chosen. Commented Jan 24, 2013 at 23:14
  • 4
    -1 not an answer Commented Jul 18, 2013 at 13:31
  • Is the plural of "anecdote" "data"? This brave answerer says yes! Commented Apr 19, 2022 at 10:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.