Have a very large project more than 70k LOC.

The project definitely needs some code refactoring in Core Framework and in other parts as well. There was NO time set in the beginning of the project for refactoring. However with time and more than 40 developers joint and left the project. From my perspective is indispensable.

What would be your key points in arguing and defending a proper software development principle?

  • 15
    70k LOC is not a very large project. I would call it small Commented Jul 24, 2012 at 10:44
  • @BЈовић True, I've inherited single source files that had several multiples of 10k LoC
    – James
    Commented Jul 24, 2012 at 10:58
  • 1
    Ouch. Reading a 10k LOC file is like reading a big book. Once you get to the end, you forgot the beginning. I have one 10k LOC legacy class in my project, and every change is a pain. Can not imaging how it is to have several! Commented Jul 24, 2012 at 11:38
  • How does a chef motivate spending time cleaning up the kitchen instead of cooking food non-stop? At the same time, maybe you can put off mopping the floors in the middle of lunch rush unless something out of the ordinary has happened and do that towards the end of the day instead.
    – wasatz
    Commented Jan 7, 2021 at 7:16
  • I hate to just plug books but you could gain a lot by reading Refactoring by Martin Fowler. In it he mentions that refactoring allows him to better understand the code he is modifying. So if there is a bug, you refactor the code so you understand, and then make a change to that understood code. Your boss doesn't want you modifying code you don't understand. :) And you wouldn't want to be changing code that doesn't reflect your understanding. It is a good argument.
    – unflores
    Commented Jan 7, 2021 at 14:03

10 Answers 10


When working on legacy or brownfield application it is tempting to do a "spring cleaning" hoping to refactor the whole thing back into shape. That is in no way justifiable use of resources. After all, how is halting development on working software (only working code can be refactored) jusitifiable? Can you guarantee the time spent on the Big Refactoring Phase is going to pay off later and not cause degeneration on the project?

How do you eat an elephant? One bite at a time. Whenever you need to implement new feature or fix a bug you see if that part needs reimprovement. Like the boy scout rule says: "Always leave the campground cleaner than you found it." Refactoring shouldn't be a separate phase, it is part of every day development.

When you get this culture of quality introduced to the development team, the quality will improve. After that there is not anything to justify to the management.

  • Uff, never tried an elephant Commented Jul 24, 2012 at 6:50
  • I try to set up this mindset in my project too. We need to do some large changes for upcoming changes, but I want to do the needed refactoring while we're going. There is no point trying to pull the *big refactoring phase without any development" card.
    – cringe
    Commented Jul 24, 2012 at 7:40
  • 4
    We did the boy scout rule. Works until there are no small bites left. There are parts that are so entangled that there are no other way, than spending time on it.
    – atoth
    Commented Aug 1, 2017 at 13:31
  • sometimes however doing just that is the last resort you have to keep something alive at all. We're there now with one large product. We've decided to freeze it for all new functionality and dedicate all effort (except for emergencies, obviously) on rebuilding it from scratch because of the 20 years of deferred maintenance making it impossible to keep going with the old.
    – jwenting
    Commented May 4, 2023 at 8:19

In general, refactoring should be done in order to enable another change you need to make to the code or as a natural clean-up step after a change has been made to the code. In that case, there's nothing to justify. Refactoring is simply part of the process of doing work on the project. The time is billed to the task you were working on when you did the refactoring.

If it ain't done in small increments, then it ain't really refactoring, eh?


All good answers here - but may I add a business dimension to this. Let me ask you WHY/So-What? (think of your pointy hair boss (PHB) :)

PHB: why?
You: It'll make things easier to fix
PHB: So-what?
You: It'll increase throughput - we'll get new builds out the door quicker?
PHB: So-what?
You: Err...Happier customers?
You: I mean increased recommendations, greater satisfaction, 
     more profit sooner due to low turnaround
PHB: Oh! Sounds nice. But it only "sounds" nice can I see it?
You: WTF?
PHB: Show me the money! (i.e. numbers please)
You: Oh! Brb...(go and put some numbers in simple spreadsheet to make your case)

Basically you must make a business case - run some numbers to clarify your thought process and get the numbers to reflect the 'benefit' objectively. You'll also know how much time it'll take, approximate costs etc. It should make sense. If it's worth it you'll get the green signal and maybe spearhead the initiative too :)

If you think how can I measure everything try this book


Imagine that you are in front of a long and huge wall. You need to go to the other side.

Either you refactor the wall in order to build a door, or you go around it.

Estimate the time for both solutions and you get your justification for refactoring.

Don't forget to multiply the time in the second solution by the number of people needing to go to the other side of the wall.


Refactoring, like any other activity, must have a clear goal defined for it. Once that goal is clear, you would consider the current project status and life cycle stage. For a development project that is 80% complete, 30% behind schedule you should justify refactoring effort based on the goal set earlier. In this example, if the code pieces were unit tested and is working fine in a development environment, it is hard to justify refactoring.

The fact that 40 developers left may not be as dramatic as it sounds. I'd expect that those developers have delivered working code that was reviewed and tested. So, unless there are known problems in this code, I'd leave it as is. The idea is that in a large project like yours, I'd expect that there were standards and procedures and that the code is not a complete mess.

Remember that refactoring will cause many if not all tests that has been made to be repeated. Also, since the refactoring of this size can't be done by a one or two senior members, the refactoring may introduce problems that did not exist. This is a risk that should not be neglected.

Having said that, it is not unusual to add tasks to a project when the unforeseen happens. So, if the developers disappeared for some reason, that that would be considered an event of a special nature and whatever actions to remedy the situation must be taken. It would be treated like a fire or an earthquake, etc.

In summary, I would not refactor large working code in a large project for no good solid technical reason, specially that we all know that most project are usually in late status.

  • 3
    One can only hope your project has tests to fail...
    – Rig
    Commented Jul 24, 2012 at 4:44
  • 2
    @Rig if there aren't, I'd start by writing some. Every bug you find, write a test which will capture the fixing of it. You have to start somewhere. There's no point refactoring anything if you're not able to objectively say "I haven't broken anything".
    – John Lyon
    Commented Jul 24, 2012 at 5:12

You don't.

In my experience, you don't justify refactoring.

By that I mean that you do not list is as a specific separate task, because it gives your manager the ability to choose the development work without the refactoring, which perpetuates the issue.

I've spent years as a consultant, being brought in to companies whose development process had gone institutionally awry. I analyzed the situation, looked at the best way to fix the code by keeping the refactoring minimal (for a first pass) but able to solve the biggest issues. I provided in-depth analysis of the most common issues, the code lines that lay at the heart of the issue, the estimated time this added to any development work, and the time needed to refactor it so it ceased being an issue.

Every. Single. Time. The response was "we don't have time to refactor, we're busy developing". And it's no surprise you get that answer. Any development team worth any modicum of salt will mention refactoring. Maybe not when things still run smoothly, but definitely once the lack of refactoring is starting to complicate the development work. Any company that persists in refusing to refactor when hitting that milestone, is going to continue refusing to refactor.

It's a compounded issue. The lack of code quality causes delays, which makes it harder to reach the deadline, which causes management to cut even more corners to try and get to the deadline, therefore lowering the code quality further, and the cycle repeats.

In their defense, it's not management's job to know how to do development. It's your job to provide them with the necessary advice that allows them to make business decisions about the development efforts. If doing development without refactoring is a bad development practice, then the advice you give should not offer it as a valid option.

How to not justify refactoring.

So I chose to no longer give these managers the implementation details of how development should be done. Presenting development and refactoring as two separate steps implies that management can choose them independently. It's not reasonable to do so, and therefore it should not be presented as an option.

When asked to estimate task A, I would no longer say:

Half a day of analysis and prep, two days of work, half a day of testing and refactoring.

But I would say

Three days.

With almost every client (7 out of 8 by my count), the refactoring discussion and constant corner cutting suddenly stopped and I was able to actually contribute reasonable quality code.

This doesn't fix existing issues though, since these tend to require a separate task of their own. It's hard to hide away the refactoring when it's the only job that needs doing.

But just like how I started omitting fine details about refactoring being part of the development work I stopped mentioning quick and dirty fixes and how much quicker they could be compared to doing a proper job. When asked how long it would take to fix bug B I would no longer say:

I can quick fix it in half a day, or properly revisit and fix the code in two days.

but rather

This is going to be two days of work.

To summarize

There's no restaurant in the world that has a special menu option where they only serve food that did not fall on the floor. The implicit expectation for any and every dish is that the food never fell on the floor.
Similarly, you should not present separate options where development happens without the necessary refactoring, because the implicit expectation is that development includes refactoring.

Institutional code quality issues in a development team, and persistently denied refactoring effort, are indications that management is making shortsighted decisions that shoot themselves in the foot, but they don't understand how the trigger is connected to the future bullet hold in their foot.

In order to protect both the project and the managers from themselves; simply start considering that essential tasks for development are by definition essential to development, and therefore fall under the "development" category and don't need to be mentioned separately. All it does is provide a bad option of picking development and excluding refactoring.

  • The specific option is nowadays very common: "toogoodtogo" is about that, food that's not healthy for supermarkets can be bought at dirt cheap prices. So yes people do like the choice between quick and dirty (food that is almost about to go bad) vs good quality.
    – paul23
    Commented Feb 5 at 13:34
  • @paul23: The "issue" with toogoodtogo-style food is not one of quality as experienced by the consumer (literally the person who consumes the food, i.e. its nutritional quality); it's one of stores rejecting this food because it does not hold to the standards that they hold themselves to (usually beauty standards or shelf life to avoid fast restocking, but this can vary). The analogy doesn't really work in relation to what I was focusing on.
    – Flater
    Commented Feb 5 at 22:10
  • Still, it's the same idea; "cheap (quick) and ugly (dirty solution)" vs "pricy (longer time developing) and good". The idea is that the customer likes choice!
    – paul23
    Commented Feb 6 at 7:19
  • @paul23: Your examples are significantly too light on the (un)informed nature of the choice the customer is making. Food safety standards exist because the onus should not be on customers to vet the entire kitchen before choosing to eat there. "The customer likes choice" is not a reason to not have these standards. Similarly, non-technical management often does not make informed decisions about technical debt, rendering their "free choice" questionable and misguided. Just because someone knows what they wants does not mean they will inevitably make the best choice to achieve it.
    – Flater
    Commented Feb 6 at 21:57

As I read in one of the other answers, eat this elephant one bite at a time. I'm involved in auditing a large international project, where team members are geographically dispersed. After building the first two versions of the software the team agreed that their approaches, style of coding and building solutions is inconsistent. They agreed to write new parts of the application following the new rules and convention and when (and only then) they have to change some of the old code, they first refactor it to meet the new convention. Everything is working quite well. The refactoring process is almost in its 5th month, some of the code is refactored, some still isn't. New features are brought in time, clients are happy, devs are happy, QA team is also happy. A win-win situation :)


Main point of refactoring is to make things easier in the future. You cannot show profits of refactoring unless you compare multiple long-term projects few done with and few without constant refactoring. It is generally accepted across developers, that refactoring decreases cost of maintenance and implementation of changes, but those are hard to prove from business standpoint. The key reason to implement refactoring is to reduce Technical Debt.

Also, refactoring should be continuous process and time spend on the refactoring should be included in development task itself. Having special "refactoring task" is not good idea.


Use images showing how development speed is affected.

enter image description here

This graph shows what happens if you don't refactor. If its 70K loc that's a mess with no unit tests. I'd say it needs to be re-written.

Use graphs, statistics, and studies. Managers will listen to these things usually.


  • 1/2 a day testing and refactoring, for 2 days development work? I think your metrics are badly skewed!
    – Andrew
    Commented Jan 7, 2021 at 12:44

If refactoring takes so long that you need to justify it, then don’t do it. When do you do it: when you have to make a change in old code, and refactoring + making it work reliably is less or not much more work than merging your changes into the existing code.

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