3

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?

7

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. – Marjan Venema Jul 6 '13 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). – Marjan Venema Jul 6 '13 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. – e28Makaveli Jul 6 '13 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. – e28Makaveli Jul 6 '13 at 13:02
  • 2
    @e28makaveli - Ask your team lead about what deadlines they are under and why they don't want you to do it now. – Rocklan Jul 6 '13 at 14:54
3

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.

1

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. – e28Makaveli Jul 6 '13 at 13:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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