How to prove business benefit in software refactoring?

Question

By these days I work in a legacy code that uses JAVA. The project has a code tightly coupled and low cohesion. All my teammates suffer to make changes in the software, one reason is that we haven't any behaviour test to secure that changes in software won't broken everything.

At the company that I work, the managers do NOT care about the software by itself, just about money and money. I mean, usually they don't create tasks to refactor or create tests, cause it will be a waste of money, they say: "the software is already working".

As a software engineer how can I prove to managers that it worth to refactor the code? Is there any metric to use? is there some methodology? I wanna know something like, how much money can I save if I refactor my software?

Everybody knows that the cost to add new features into the software become onerous, but how to measure it?

Answer 1

I mean, usually they don't create tasks to refactor or create tests, cause it will be a waste of money, they say: "the software is already working".

If it is already working, why do they employ you and your teammates to make changes? Clearly it might sort of "be working", but they want it to work better, to allow them to make more money. Otherwise they are just wasting money employing you.

So given they want to make changes, they should make those changes as efficient as possible. Quick, dirty changes are inefficient as they store up trouble for later. Every time you make a change, you all risk the entire application collapsing around you, or each change will just take longer and longer.

If they are in the business of making more money to sell the company in the short term, you are wasting your time and their money trying to write good code; that runs counter to the aims of the company. If they are in it for the long haul though, then investing time in refactoring will pay dividends in the long run as it won't get ever more expensive to make changes.

So your choices depend on their business plan. Ask them if their aim is to make lots of money in the short term only before selling. If so, go with it or change jobs. If not, then often the best thing to do is do the job properly without telling them directly: increase your estimates per task to include refactoring time. If you want to do it properly, quote a price to do it properly.

Answer 2

Although I haven't had the chance myself to put this into practice, the Consortium for IT Software Quality recently released their Automated Technical Debt Measure standard as a mean to measure and calculate an issue tightly related to refactoring (or rather, the need for it).

That's the best chance to make the managers understand the need for periodical refactoring of legacy code. Of course, most developers will see the benefits in far less elaborated metrics.

Answer 3

I'm confused by the statement "cost to refactor a software become onerous" the cost of refactoring is a fairly linear thing. It's the cost of adding new features into a mess that grows exponentially. That's what you need to focus on. As a start, can you pull together stats on the development team performance over time? The management might be able to give you this information. Try asking for it.

Often management can see this happening but doesn't understand why. At the same time the development team starts talking about things like tests and refactoring. It's important to understand that from a business perspective, tests and refactoring provide no value added to the product. It's not a feature that adds or retains revenues. They can't advertise: "now with unit testing!" So from their perspective, productivity is lagging and your answer is to do more unproductive things. It's not going to be welcome, but it's necessary.

The point you need to be clear on this that these are things that are needed to keep costs under control. Try analogy: If you never change the oil in a truck, eventually it will fail and the costs to repair it will far outweigh the cost of proper maintenance. Railroad operators don't like paying for track maintenance (it's pure cost!) but if they don't they don't have a business. The Pony Express had a fresh horse every 16 kilometers for their riders. It wasn't because they like owning and caring for lots of horses and maintaining so many stations, it was so they could be really fast.

You need to make them understand that what they are doing is like trying to run a pony express but by flogging a single horse the whole way. It's going to get slower and slower and eventually stop moving entirely. Once you get them to understand the idea, you need to explain that the horse is almost dead. If they don't invest some time in rehabilitating it, they will never be able to keep up with their competition. You are not asking for time to tidy up. You are asking for an investment in time so you can make things move fast again.

If you need a historical example to provide them with, you need look no further than Microsoft. I recall reading an interview with one of the top development managers about how all that mattered was adding new features and cleaning up old code didn't matter. It was boastful, they were so much smarter than their competitors by ignoring about the pile of manure the were building upon (I tried to find this but it was a long time ago and I can't remember the name. I want to say it was Allchin but I'm not positive. Any help?) IIRC, this was right around the time of Longhorn which was to become Vista. It's not too hard to see how those choices lead to MS losing it's dominance to it's competitors.

Answer 4

Refactoring is an integral part of software development... well... at least it has become as such for me.

I therefore always include the necessary time to refactor the parts that needs refactoring in order to implement the feature or solve the issue cleanly. By cleanly here I mean that I try to leave the code base in a better shape than it was before I started.

Now that does not mean that I will re-write the whole thing, I will refactor just the parts needed to get the job at hand done.

Sadly for some code base this is simply not possible. Their overall structure and architecture was neglected for so long that they are effectively "too far gone". Typically such systems are extremely expensive to maintain or to introduce new features in, a large part of this due to the technical debt that was incurred throughout it's lifetime.

Now I do sympathize with the bosses here. For them the bottom line is dollar and cents. You must therefore speak that same language if you wish to justify some major refactors. As you already know, the very definition of a refactor is a zero sum enterprise regarding the functionality of the software itself. Where you can mark some points however is if you can convince (yourself first, then them) with objective measurable arguments that the refactor will have an impact on other metrics such as deployment time, testability (therefore stability, though this can be harder to measure) and in the overall cost this software incurs in maintenance.

If your refactor would reduce intervention time by developer by (say) half while at the same time provide better guarantees that the overall stability will improve then you might have a point with them. Next is to assert how long this refactor work will take and measure it up against the gains ... get a positive balance... go for it... it's still negative, well, either dig further either until you find a positive balance or until you realize that the cost of making it good is so great that it's just not worth it.