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, no registration required.

This question already has an answer here:

Currently I am working on a code best described as C code living in C++ body. However I haven't been able to convince power that be to re-factor on ground of ease of maintenance.

What in your opinion is the best argument for refactoring the code.

share|improve this question
add comment

marked as duplicate by gnat, BЈовић, MichaelT, GlenH7, Kilian Foth Jul 28 '13 at 12:48

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

7 Answers

up vote 18 down vote accepted

The only way to get a business to agree to a refactor is to show them it will save them money. I dont mean just tell them, you need to be able to say we will save x days on bug type y saving us z pounds.Or in terms of savings when it comes to adding features.

It's all about the money.

Edit: I'm assuming this code is now live or late stage development. Refactoring during dev is a whole different question.

share|improve this answer
2  
That's the only reason to refactor at all, in my opinion. Otherwise, do it in your free time, if it bothers you so much... +1 –  Rook Nov 25 '10 at 20:58
    
Thanks @Rook Oh it bothers all right but not enough to spend my free time :-) –  Gaurav Nov 25 '10 at 21:00
1  
Re factoring code "because it bothers you" is poor reason to explain why 4 new bugs have appeared in this stable product. –  Ptolemy Nov 25 '10 at 22:01
add comment

Just do it as you go. In my experience, very few projects warrant a wholesale re-factoring of the code as a separate project. If there are pieces of the code you would never get to because they don't need modification, then the value of refactoring them is probably dubious anyway.

share|improve this answer
    
Yes that's exactly how I am approaching this. –  Gaurav Nov 25 '10 at 21:06
1  
I was lucky enough to experience a large scale refactor. An entire six weeks dedicated to refactoring and adding tests. Sadly, it was a pretty big failure. I doubt management will ever give it another go. –  Rob P. Oct 3 '12 at 10:25
add comment

You don't tell the taxi driver how to drive his car.

You don't tell the hairdresser how to cut your hairs.

You don't tell a coder how to work with his code.

If you think your code needs refactoring. Refactor it.

share|improve this answer
3  
During Dev I would agree. But once it is working it comes down to your time being bought and paid for. You wouldn't expect to pay the taxi fare then have him charge you again.because he went and did the journey again on a better route. –  Kevin D Nov 25 '10 at 21:48
    
Refactoring takes times, which usually customer would like you to spend on developing new function. customer always want to reduce the development time and cost so they pay us less. –  didxga Nov 26 '10 at 3:38
1  
If the taxi is not going straight to yout destination using the best path he knows, he is abusing you. If the developer decide to refactor just for fun, he is abusing you too. –  user2567 Nov 26 '10 at 7:26
    
These comments all apply mainly to contractors who are working hourly for some "customer". I've always been salaried and refactoring has been either explicit priorities or people/managers accepted without too much complaining if you just did it. –  Kevin May 19 '11 at 4:09
add comment

I can think of three arguments for refactoring that I have used that have actually convinced sceptical directors.

  1. Architectural change to allow additional types of desirable features.
  2. Removing a block of code that has an established track record of bugs combined with a history of fixing a bug and a new bug appears.
  3. Poor security / Poor performance that is affecting sales.

Using arguments like "the code is badly written" and "its really hard to understand the code" do not typically work.

share|improve this answer
add comment

Most reasons are dealing with probabilities which makes them difficult to count, especially if the willingness to take risks is high. Better maintenance? If nothing goes wrong, you won't have to touch it. Better portability? If we never change the running system, we won't need it. Guaranteed future? Who knows if we will need the functionality of this code in a few years time at all? Code's a dead end? Who knows if we will ever build code on top of that crap. Security issues? We don't believe in evil hackers. Programmers having fun to make something bright and shiny? We don't pay them to have fun. Easier to manage? So we would need less qualified programmers, paying them less money? Ahh, now you've got a point...!

The last argument was a joke, but I think you will need to tackle your request with real benefits and depending on what's high on the agenda of your bosses you will need different arguments. My list above is maybe useful as a starting point...

share|improve this answer
add comment

Writing code is much like growing a garden - it needs to be pruned and tendered while growing often or it will just turn into an ugly mess which no one will want or even touch with fear some twig will break and crash the whole bush.

share|improve this answer
    
+1, you made a really good metaphor, it's convincing and intuitive, but usually cost is the first factor to impact customer's decision. How can we convince customer if you don't do refactoring, you will spend more. –  didxga Nov 26 '10 at 3:34
add comment

As with everything examples are the best way. Some examples you can give:

  • Hard to change code: Bug X took 3 days to fix caused by code issues a,b,c
  • Tight coupling: Fixing Bug Y introduced bug G, fixing both causes bug F
  • Hard to read: It took 1 whole day to investigate bug C
  • Bad cohesion: Introducing feature D required dependency on F, which is unrelated. This causes problems such as circular dependency problem a, build time increase b etc...

To put this simply if you can draw a cause and effect line and illustrate with bug tracker records, e-mails and other forms of proof that indicate that there is a problem that should motivate refactoring quite easily. "It shouldn't have taken 2 weeks to implement feature X!"

There are tools out there that can help you motivate your refactoring too. They can draw dependency graphs or show code complexity, duplication etc. If a tool reports thousands of warnings and management ignores it then there is no hope for management.

These focus on code structure changes. Small refactorings like naming conventions and pulling up into base classes are things that I consider part of my job, and I don't ask permission to do it. If it's going to impact productivity or delivery date significantly then it is worth asking permission.

share|improve this answer
add comment

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