current community

your communities

more stack exchange communities

Stack Exchange
tour help
Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.
up vote 10 down vote favorite
2

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?

share|improve this question
    
See RECONSTRUCTION –  hakre Jul 18 '13 at 9:29
1  
Start maintaining a mess yourself and be the judge. –  user61852 Jul 18 '13 at 11:33

2 Answers 2

up vote 16 down vote

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.

share|improve this answer
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 Sep 15 '11 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♦ Jul 18 '13 at 10:23
up vote -1 down vote

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.

share|improve this answer
5  
Not really. the complexity of the task performed by the software must be distinguished from the added complexity caused by the implementation chosen. –  reinierpost Jan 24 '13 at 23:14
4  
-1 not an answer –  Dave Hillier Jul 18 '13 at 13:31

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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