When to delete newly deprecated code?

Question

I spent a month writing an elaborate payment system that handles both credit card payments and electronic fund transfers. My work was used on production server for about a month. I was told recently by the client that he no longer wants to use the electronic fund transfer feature.

Because the way I had to interface and communicate with the credit card gateway is drastically different from the electronic fund transfer api (eg. the cc company gives transaction responses immediately after an http request, while the eft company gives transaction responses 5 business days after an http request), I spent a lot of time writing my own API to abstract common function calls like

function pay(amount, pay_method,pay_freq)

function updateRecurringSchedule(user_id,new_schedule)

etc..

Now that the client wants to abandon the EFT feature, all my work for this abstracted payments API is obsolete.

I'm deliberating over whether I should scrap my work. Here's my pro vs. con for scrapping it now:

PRO 1: Eliminate code bloat

PRO 2: New developers do not need to learn MY API. They only need to read the CC company's API

PRO 3: Because the EFT company did not handle recurring payment schedules, refunds, and validation, I wrote my own application to do it. Although the CC company's API permitted this functionality, I opted to use mine instead so that I could streamline my code. now that EFT is out of the picture, I can delete all this confusing code and just rely on the CC company's system to manage recurring billing, payment schedules, refunds, validations etc...

CON 1: Although I can just delete the EFT code, it still takes time to remove the entire framework that consolidates different payment systems.

CON 2: with regards to PRO 3, it takes time to build functionality that integrates the payment system more closely with the CC company.

CON 3: I feel insecure deleting all this work. I don't think I'll ever use it again. But, for some inexplicable reason, I just don't feel comfortable deleting this work "right now".

CON 4: There's also the issue of the database. If I delete my business logic code, then normalize the database (which will end up with a new db schema), it will be difficult to revive this feature because of data migration issues. Whereas, if I keep the existing code against the existing database, it's more trouble for the developer to maintain, but no fear of losing anything.

So my question is, should I delete one month's worth recent development? If yes, should I do it immediately or wait X amount of time before doing so?

Additional details I added CON 4

Answer 1

Delete it. No reason to keep it around. I am sure you are using a version control system, so you can always get it back on the off chance that you need it. No one likes losing a month's worth of work, but its a sunk cost. Whether you keep it or not you aren't getting that time back.

Answer 2

Using a VCS properly means never having to feel guilty about deleting code.

Answer 3

You should not only delete the code, you should delete the requirement that caused you to write the code. Then delete all the decisions you made as a result of the requirement.

For instance, you said you needed to abstract the interactions with the two systems because they were so different. There are no longer two systems, so delete the abstraction. Any other decisions you made because of two systems need to go.

Yes, you may wind up using some of this code again, which is why a version control system is a Good Thing. But the next time you have a requirement like this, it's likely to be a different second system, which would lead to a different abstraction.

That is, it will lead to a different abstraction if you don't tie it down to your original abstraction by keeping the old code.

Answer 4

As I read your question, you are handling recurring payment schedules, refunds, and validations, using the code which might be deleted. The code currently works fine as far as you know.

PRO 3: Because the EFT company did not handle recurring payment schedules, refunds, and validation, I wrote my own application to do it. Although the CC company's API permitted this functionality, I opted to use mine instead so that I could streamline my code. now that EFT is out of the picture, I can delete all this confusing code and just rely on the CC company's system to manage recurring billing, payment schedules, refunds, validations etc...

CON 2: with regards to PRO 3, it takes time to build functionality that integrates the payment system more closely with the CC company.

I think you overlooked the issue that you might introduce bugs into a system that is currently working well. If your code to handle recurring payments, etc., is working, are you sure that it's worthwhile to throw all that over to the CC API?

It sounds like there might be some risk inherent in making these changes, which should be considered in the ROI. Also, speaking of Return On Investment, you are talking about spending paid time to rip out the EFT code, right? Otherwise, that would be another reason not to.