6

When a project has reached end of life and is being retired, either because the technology is obsolete, a newer version of the program has been rewritten, or it no longer solves a problem that is needed to be solved, what should be done with the code? Should it be deleted, or kept for future reference?

This also applies to projects that someone might develop as a contractor, and the company which needed them goes out of business.

5
  • 5
    It should be made open source! Commented Apr 28, 2011 at 3:37
  • 1
    Thrown in the tar pit :) Failing that open source (my preference would be MIT/BSD) sounds like a sensible option as muntoo commented. Commented Apr 28, 2011 at 3:44
  • 3
    open source is fine for generic apps but not for private code , say a banks old code? you cant open source that!
    – DPD
    Commented Apr 28, 2011 at 4:09
  • 5
    Keep it. Back it up, on multiple media, in multiple locations, then test the backups. By the time you urgently need it, most of the media will have gone bad.
    – Phil Lello
    Commented Apr 28, 2011 at 4:44
  • 1
    I would burn it. The only problem is how...
    – John Shaft
    Commented Apr 28, 2011 at 7:18

8 Answers 8

4

Keep it.

You may have to some day inspect the code to see e.g. assumptions, or how a specific thing was solved ("you had something that did this, and we want the same thing") and it is a bit easier if you actually have it.

Source repositories are really cheap to keep on a corner of an official server somewhere.

4
  • That might be looking too much ahead into the future. You'll probably not gonna need it anyways. How many times do we go ahead and say "Oh! Let me add this awesome tweak to the system. The clients are surely gonna need it later"? I like to think a little bit more about the now :) Commented Apr 28, 2011 at 21:07
  • 1
    @edgar, "probably"... Consider it insurance.
    – user1249
    Commented Apr 28, 2011 at 22:01
  • ørn: LOL, have you heard about YAGNI en.wikipedia.org/wiki/YAGNI? Commented Apr 28, 2011 at 22:34
  • 1
    @edgar, this is not discussing what should go into new code, but saving the old code in case it is necessary to look back in time.
    – user1249
    Commented Apr 28, 2011 at 22:39
13

If code has made it into the wild, you should never delete it. Users are very good at desperately needing help 5 minutes after you destroy your ability to support it.

With the contracting side of your question you may be limited by confidentiality issues. I had one government agency expressly prohibit me from taking anything offsite, be it electronic or physical. But if you can get away with it I encourage you to keep a backup of anything you do for other parties - this approach has made me a hero on several occasions.

I guess my answer boils down to: expect to need the code some day.

9

Storage space is really cheap nowadays, so personally, I would keep an archive backup just in case.

3

Put it under a FOSS license.

If not possible, document every bit of it starting at the specs, design, bugs faced and fixed and publish this report under a FOSS license. This report will help you, and, others, learn from your mistakes. Besides, if someone wants to write a similar program or program to the exact specs, they will have you to thank.

2

I would recommend using a version control system (git/mercurial/subversion) and deleting the not-to-be-used-anymore code.

  1. Just use the version control system as a backup for the "dead" code. Then, unless it's a public API, proceed to delete it! The deleted code will always be in a revision where you can go to when necessary.

  2. If it is a public API then the process is a little longer and more tedious. You first have to mark it as deprecated, so that your API users would know what's coming, and then in future releases you might delete the implementations and leave the classes/interfaces/functions defined and marked as deprecated.

By using VCS, either distributed or centralized, you'll have access to the deleted/deprecated code, so there's not much to fear.

5
  • Problem with deleted code is you need to know where it was in order to be able to find it again.
    – user1249
    Commented Apr 28, 2011 at 5:39
  • That's solved with a repository history browser :) Commented Apr 28, 2011 at 6:13
  • not if you wasn't the one to delete it and don't know it was there.
    – user1249
    Commented Apr 28, 2011 at 6:39
  • git supports repository history full text search, see stackoverflow.com/q/44176/377657
    – rwong
    Commented Apr 28, 2011 at 6:46
  • @rwong, you still need to know it's there somewhere.
    – user1249
    Commented Apr 28, 2011 at 22:42
2

Storage is cheap, so what do you actually gain by deleting the code?

What do you gain by keeping the code in an archive where you can access it, but it won't end up in anything by accident?

What do we all suspect will happen 5 minutes after you delete the last copy (including backups) of that code?

The answers to those questions will tell you whether to keep it or not.

And, of course, open sourcing it is always an option that might give it new life in ways you never expected.

2
  • 1
    "what do you actually gain by deleting the code" you prevent yourself from being sued for letting customer code get out of their systems...
    – jwenting
    Commented Apr 28, 2011 at 6:43
  • @jwenting: Then that gives you the answer.
    – Tango
    Commented Apr 28, 2011 at 16:16
2

Keep the code but remove it from the projects ,the build process and the VCS. It will be in the VCS when you need it. But when you don't see it directly it keeps the current project easier to understand.

1

Delete it.

Just because we can store something doesn't mean we should.

  • "the technology is obsolete". Delete it. Obsolete is obsolete. It will never magically become useful again except as a plot device in TV show.

  • "a newer version of the program has been rewritten". Delete it. After 90 days of using the new software there will be enough new data that cannot be backported to the old version that you can safely delete it. It's useless.

  • "it no longer solves a problem that is needed to be solved". You might keep it just in case the problem resurfaces. The odds of the same problem (in the same context, which can be solved by the same problem) are almost zero.

Code is not a precious artifact that future archaeologists will want. It's not an heirloom that you'll pass on to your children. It's not a corporate asset that makes money or reduces cost. It's just mental clutter.

Delete it. Please.

  • "projects that someone might develop as a contractor". The customer owns the code. Delete your copy ASAP. When make changes to their copy, your copy is useless and confusing.

  • "and the company which needed them goes out of business". That's a problem for lawyers managing the assets of the defunct company. That's not your problem. A duplicate copy of the code doesn't help anyone. Delete your copy after you get any final payment if you're still owed money.

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.