Code you wrote yourself, especially generic libraries will always be useful for you as long as you use it on a periodic basis. I have some C++ code I wrote back when I was 13 in my first courses in college which is part of my current startup codebase.
The question is would these tools be useful for someone else? Would these utilities make other programmers more productive? Would someone pay you to buy your code? (except for its didactic/historic/collector value)
I see "On LISP" goes for about 200$ on Amazon despite the fact that you published it as a free pdf.
I think at least one part of the author's argument bears examining: the author says, "The cold reality that software companies try to ignore is that ANY major piece of software needs to be rewritten from the ground up eventually." He makes a good case for it, yet Joel Spolsky has this to say:
"... the single worst strategic mistake that any software company can make:
They decided to rewrite the code from scratch."
...
"There's a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong."
How do you square the two observations? I think that since you can't reasonably go down both roads with the same project at the same time, one doesn't really compare the results of one option to the real results of the other, but rather to the imagined result we would have gotten if we taken the other road.
In short, neither rewriting nor endlessly patching is going to produce results as good as we think we ought to have; both would be a major pain in the butt. The devils always lie in the details, details you won't hit until you try one or the other. I'm inclined to think Spolsky is closer to the truth, but I'm suggesting it's not as clear cut as either position would have you believe.
The other point of the O'Reilly article, however, is spot on: "most companies let the value walk out the door (either through layoffs or attrition)"
That's why I (usually) like the "rewrite" option. I can't think of a better way to learn what the program does than by rewriting it and getting it to work.
As I've told many clients before, "It doesn't matter how soon we start, just how soon we finish." Sometimes, rewriting gets you to the finish line sooner.
Joel's thesis is that crufty old code has bug fixes in it that will be inadvertently unfixed in a rewrite. He concedes the point that rewriting is much faster than heavy refactoring.
Experience says Joel is wrong. The old code is a mess because people got lazy or weren't quite sure what direction they were going, not because it accumulated value as bugs were fixed. This other guy is right. If the experts on the current code think it's faster to rewrite than go through a todo list on the current code, they're probably correct.
I think you can likely make the decision by empirical means. How many moving parts and roughly how much code can be removed in a rewrite?
Okay, at first, I thought nice spin! He has a good point!
But then I remmembered Cpan! Okay, so moral is if you document your code create useful libraries you can save a lot of code from turning useless
I can also see, that in most work places expecially in IT departments of non IT organizations many still don't use a single repository for their code or document their code and projects, this is why many code just die when the employee who wrote it leave
OK, maybe I should have been more specific. Somehow that article really annoyed me: "code is only worth 0.83$, because I can code a for loop in 30 seconds". Hm, not very convincing. "Code is worthless once the original programmers are gone" - just a claim, without any statistical backing. Personally I think it is conceivable to actually dig through somebody elses sourcecode and understand it.
I wonder if such articles are just written for "karma whoring", or if they really express a heartfelt concern of the author.
