Refactor working code for reuse or duplicate?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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".

Answer 4

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?