I have always avoided duplicating code regardless of the circumstance. For example, if I have a working piece of functionality that needs to be re-used by different entities, I always refactor to make this functionality available. Under no circumstance would I duplicate code. I am probably a little rigid when it comes to this but I really do not like duplicating code.

I currently had a slight disagreement with our Team Lead who suggested that instead of refactoring, I should copy entire piece of functionality I require into a different class and then we can decide how best to refactor at a later date. This is even after confirming that my previous refactoring efforts did not break any of the unit tests.

I further had this conversation today with my previous manager, and his mentor, who both sided with my Team Lead. Their argument is incurring technical debt is OK, and almost always preferable, especially if you are running into time constraints, which I understand. My counter argument was yes, we do not want to skip deadlines but one must always consider the cost of refactoring and this usually should be the first instinct, especially if we are simply moving functionality into a new location that renders it accessible to all. Proper unit test can also ensure that refactoring efforts do not break existing functionality. Also is it not always better to pay off the debt now rather than later? I can only imagine what this task will entail if all members of the team simply duplicated code.

Suffices to say that we had to agree to disagree. In his book titled Clean Code, Robert Martins emphasis continuous refactor during development so I was surprised by the response of my previous manager.

What are you opinions on this?

  • Duplicating code leads to bloat. I always opt for refactoring for reuse.
    – CPlus
    Commented Jul 16, 2023 at 3:26

4 Answers 4


If your team lead, previous manager and mentor are all saying that you don't have the time to refactor now because of time constraints, then you don't have time to refactor it now. Note it, stick a TODO in there and refactor it later.

You're not being held responsible for the delivery date. They are. You're probably not aware of what's going on with the bigger picture, and you don't need to explain to the CEO/board why the project is two weeks late. Saying "We wanted to have a cleaner code base now, instead of in a months time, so we're delaying the project, and now your job is on the line" is not a good excuse.

In an ideal world you would always be able to refactor and not incur technical debt. It's always the preferred solution, no-one is arguing that. I too hate duplicate code - I'm actually in the situation now where I've inherited a lot of copy and paste code and it's going to be a nightmare to fix up, but the business did what they needed to do to deliver the project, and they can now afford to spend the extra time to clean up the code.

  • 6
    If OP is not aware of what else may be going on and the lead, mentor and previous manager are just time constraining him/her, then that lead, mentor and previous manager have serious communication problems. It never helps to restrict/restrain anybody without giving proper motivation. Giving proper motivation for the restriction/restrainment actually is the best way to make people want to comply. Commented Jul 6, 2013 at 9:20
  • 2
    Also, a simple "we'll do it as soon as this code is touched again" is a promise that goes a long way to helping people accept the decision. There are too many instances where you know that you'll never get the time to do the refactor because there is always something else that is more important or another deadline that needs meeting (usually because schedules are way too optimistic). Commented Jul 6, 2013 at 9:24
  • @MarjanVenema, I agree with both your comments. There is an assumption that we will have the time to refactor later. No one wants a project to miss deadlines. But if you have several members of the team duplicating code all over the place, I think this practice actually will introduced inefficiencies. Commented Jul 6, 2013 at 12:52
  • @LachlanB, I agree with what you are saying but my stance on this is that refactoring is part of the development process and one should approach this on a case by case basis. For example, if there will be multiple consumers of this piece of functionality, it will more cost effective to refactor now. Otherwise, it becomes more costly to duplicate this piece of functionality. Again, I am not refactoring just for the sake of writing beautiful code. Mostly to reuse functionality that is already proven to work. Commented Jul 6, 2013 at 13:02
  • 3
    @e28makaveli - Ask your team lead about what deadlines they are under and why they don't want you to do it now.
    – Rocklan
    Commented Jul 6, 2013 at 14:54

Yes, incurring technical debt is bad. Yes, you should always refactor as you develop.

In an ideal world.

Unfortunately, we do not live in an ideal world. Sometimes, we have to do things we're not happy about. I'm pretty sure your Team Lead is aware that not taking the time now will mean more work in the future - but he's had to make a decision. There are many reasons why this would be so.

Ideally (that word again), in this situation, there should be an allowance for some time to refactor after the deadline before moving on to new work. If that doesn't happen, then there is definitely some code management smell there - but your disagreement with the practice will likely not have an effect, and any attempt to force the issue will just make your position more uncomfortable.

As we only have your side of the discussion to go by, it's hard to answer in a balanced way - for example, you don't really say how big this bit of functionality is. Also, you don't say how often this situation occurs.

Ultimately, if you don't like the practices at your current organisation, there are plenty of others out there that you would fit in better at.


Your manager is about to sacrifice code-maintainability because the project is running out of time. In the short term it is much faster to duplicate code ("copy&paste inheritence") and add a "to do" than to refactor now.

From my experience you will never have the time to do the refactoring later :-(.

You can give management a time estimate how much extra time is required to do the refactoring and if they still say no you have to do what they want.

If you write a short email that summaries the political management decision so you are protected from a possible later blaming-game because of "the bad code quality with so many code duplicates".

  • 1
    Yes, providing a time estimate is a great idea although one could also argue that it takes time to come up with a time estimate :), further risking the project's deliverables. Commented Jul 6, 2013 at 13:08

Also is it not always better to pay off the debt now rather than later?

No. Debt can be good, both economically and technically. It’s a trade off and as with all trades you get something for what you give up.

Debt gives you what you need now, now, not later. Paying it off too soon and you can be debt free and out of business.

If the amount of time is significant enough that you need to get your Team Leads approval, then you should probably do it his way. If the TL simply suggested it, but doesn’t require it, ask yourself what you gain by refactoring now vs later. You are giving up time now, is the only gain time later? How much time do you expect it to take later? An hour today could easily be more valuable than 8 next month.

Also, you should consider what kind of workflow you have, can you put in a task or backlog item for joining the two implementations back up and is there a chance that will get worked before you leave the company?

  • "Debt can be good, both economically and technically" - I wonder if debt were good then it wouldn't be called debt, it would be called credit!
    – Steve
    Commented Sep 22, 2020 at 9:04
  • @Steve: credit has different meanings, if it's credit/debit columns in double book keeping, they are essentially the same thing (and of course must have the same value), and just identify the primary account. If you are talking personal finances, then credit isn't debt it's an offer to allow additional debt.
    – jmoreno
    Commented Mar 24 at 23:00
  • I was talking about this supposed concept of "good technical debt". "Technical debt" doesn't mean a trade-off that may be good or bad. It means a harmful trade-off overall, in the view of the person using the term. If you're arguing that the trade-off isn't harmful but beneficial overall, then you're denying that it is technical debt, but instead insisting that it is some kind of "technical asset".
    – Steve
    Commented Mar 25 at 7:47
  • @steve: it’s not an asset in itself, but sometimes necessary in order to obtain an asset. If a company has the choice of paying off the debt on a capital asset immediately but not being able to make payroll, or over 15 years and making payroll, then it needs to keep the debt. If it needs a new piece of capital equipment in order to be competitive and doesn’t have enough cash to pay for it outright, then it needs to take on that debt. Firefox barely has a share of the browser market,which can be attributed to them trying to eliminate technical debt.Debt used to obtain necessary items is good.
    – jmoreno
    Commented Mar 25 at 10:34
  • A quote from Blaise Pascal describes “good” technical debt perfectly: “I have made this [letter] longer than usual because I have not had time to make it shorter.” Technical debt can be used to buy time, which can be of incalculable value.
    – jmoreno
    Commented Mar 25 at 10:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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