3 ms·

This argument (don't re-write) sounds great to laymen and managers because they see "the code" as the sole artifact of the development effort. The flaw here (k

This argument (don't re-write) sounds great to laymen and managers because they see "the code" as the sole artifact of the development effort. The flaw here (known to almost any developer) is that the code itself, the physical files and such represents the work of developing an application as completely as a photograph of a boxing match represents boxing itself. Evidence of this can be seen in the many examples of companies "buying out" an application by taking only the source and attempting to run with it. The results are rarely, if ever, spectacular. Most of the application is in the minds of the developers. Take away his source and ask a developer to re-write an application and you are guaranteed to get a better program. Why? Because by the end of the project you know more than you did at the beginning, and when you re-write the code from scratch you can leverage this knowledge on all of the code, not just the code you wrote after you learned these lessons. In this way it is impossible to re-write something (unless you are starting with new developers as well), just like if you asked Stephen King to re-write (as in, re-type) The Shining...

jderick 17y ago
I agree. So essentially the "rust" in a codebase is the differential between what your developers know about the code and what knowledge is embedded in the code. Since it is much harder to read code than write it (at least, for "awful" codebases), once code has rusted enough it is best to just throw it away. On the flip side, if you are able to keep your developers up to date on the codebase, you will save yourself a lot of trouble.
tapostrophemo 17y ago
"Most of the application is in the minds of the developers. Take away his source and ask a developer to re-write an application and you are guaranteed to get a better program." Well, not always. What about the edge cases the developer has long since forgotten? Unless you've also got a good test suite that covers those cases, you're exposing yourself to the risk of missing those edge cases in a sans-source re-write.
- jasongullickson 17y ago
  You're absolutely correct. However I would argue that, if you are in a situation where the developer (developers, development team, etc.) is no longer is aware of these edge cases, you have bigger problems than a shipping delay due to a re-write.
tophat02 17y ago
But one of Joel's points is that, by the time you get around to rewriting something, you usually aren't dealing with the same programmers. If this isn't the case, and you have the same core team available, then I agree, it is sometimes better to rewrite. But these days, refactoring techniques and testing methodologies are much more concretely defined and practice, so it still may be possible to essentially "rewrite" the code without having an X year shipping delay.
- jasongullickson 17y ago
  Agreed, this is why small, dedicated teams (for example, those with skin in the game in regard to the company's success) is the best insurance against this unfortunate scenario (loosing the original developers).

jderick 17y ago

I agree. So essentially the "rust" in a codebase is the differential between what your developers know about the code and what knowledge is embedded in the code. Since it is much harder to read code than write it (at least, for "awful" codebases), once code has rusted enough it is best to just throw it away. On the flip side, if you are able to keep your developers up to date on the codebase, you will save yourself a lot of trouble.

tapostrophemo 17y ago

"Most of the application is in the minds of the developers. Take away his source and ask a developer to re-write an application and you are guaranteed to get a better program." Well, not always. What about the edge cases the developer has long since forgotten? Unless you've also got a good test suite that covers those cases, you're exposing yourself to the risk of missing those edge cases in a sans-source re-write.

jasongullickson 17y ago
You're absolutely correct. However I would argue that, if you are in a situation where the developer (developers, development team, etc.) is no longer is aware of these edge cases, you have bigger problems than a shipping delay due to a re-write.

tophat02 17y ago

But one of Joel's points is that, by the time you get around to rewriting something, you usually aren't dealing with the same programmers. If this isn't the case, and you have the same core team available, then I agree, it is sometimes better to rewrite. But these days, refactoring techniques and testing methodologies are much more concretely defined and practice, so it still may be possible to essentially "rewrite" the code without having an X year shipping delay.

jasongullickson 17y ago
Agreed, this is why small, dedicated teams (for example, those with skin in the game in regard to the company's success) is the best insurance against this unfortunate scenario (loosing the original developers).