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.
0
Add a comment
|
7 Answers
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.
-
2That'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– RookCommented Nov 25, 2010 at 20:58
-
1Thanks @Rook Oh it bothers all right but not enough to spend my free time :-)– GauravCommented Nov 25, 2010 at 21:00
-
2Re factoring code "because it bothers you" is poor reason to explain why 4 new bugs have appeared in this stable product. Commented Nov 25, 2010 at 22:01
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.
-
-
2I 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.Commented Oct 3, 2012 at 10:25
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.
-
3During 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 DCommented Nov 25, 2010 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.– didxgaCommented Nov 26, 2010 at 3:38
-
1If 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.– user2567Commented Nov 26, 2010 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.– KevinCommented May 19, 2011 at 4:09
I can think of three arguments for refactoring that I have used that have actually convinced sceptical directors.
- Architectural change to allow additional types of desirable features.
- 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.
- 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.
answered Nov 25, 2010 at 21:59
-
"the code is badly written" would then connect back to something tangible, like performance, readability, security or bugginess. As for "its really hard to understand the code" I agree it is a harder route but code that is hard to read is hard to understand and will lead to bugs, and they cost money. So there is definately arguments for just making the code look pretty, consistent and reader friendly as well. Commented Nov 21, 2016 at 13:22
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...
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.
-
+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.– didxgaCommented Nov 26, 2010 at 3:34
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.
