Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
5  
It should be made open source! –  muntoo Apr 28 '11 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. –  Thomas James Apr 28 '11 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 Apr 28 '11 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 Apr 28 '11 at 4:44
1  
I would burn it. The only problem is how... –  John Shaft Apr 28 '11 at 7:18

8 Answers 8

up vote 4 down vote accepted

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.

share|improve this answer
    
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 :) –  Edgar Gonzalez Apr 28 '11 at 21:07
1  
@edgar, "probably"... Consider it insurance. –  user1249 Apr 28 '11 at 22:01
    
ørn: LOL, have you heard about YAGNI en.wikipedia.org/wiki/YAGNI? –  Edgar Gonzalez Apr 28 '11 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 Apr 28 '11 at 22:39

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

share|improve this answer

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.

share|improve this answer

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.

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

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.

share|improve this answer
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 Apr 28 '11 at 6:43
    
@jwenting: Then that gives you the answer. –  Tango Apr 28 '11 at 16:16

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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