"The idea that new code is better than old is patently absurd."
jeje.

"Old code has been used."
mmmmjajaj.

"It has been tested."
jajajajajaj

"Lots of bugs have been found"
Vale, eso sí es una verdad innegable.

"and they've been fixed."
juasjuasjuasjuasjausjuas

"There's nothing wrong with it."
JOOJJOJOJOJOOJJOJOJAAJJAAAAAA

Ahora en serio. Las extrañas excrecencias, verrugas y cicatrices en el código de las que habla Joel, explicando que son bug fixes, es precisamente una señal de que el código es malo (poco robusto). Se puede escribir teniendo en cuenta que van a haber problemas no previstos. En ese sentido, la herencia es tu amiga. Cuantas más verrugas, más acoplamiento y peor se vuelve el código. El día que al becario que escribió la función se le acabe la beca y no se la renueven (porque entonces habría que contratarlo, así que mejor no renovarlo y meter a otro nuevo), el código ya no será código, sino un cuadro de Pollock al que hay que encenderle un cirio y esperar a que sea luna llena para que funcione.

La función es una balsa llena de boquetes. Aquí hay un remiendo, aquí un tapón de corcho metido a presión, allí hay un agujero que hay que tapar con el pie cada vez que alguien se monta, y aparte hay una vieja radio que no tiene nada sintonizado pero nadie se atreve a apagarla, por si acaso explota. Hombre, flotar, flota, está claro.

En fin, depende. Esta historia es excepcional. Se trata de un equipo que se encuentra con limitaciones y las resuelve empezando de nuevo. Pero no desde cero. Es la misma gente que programó el original con el conocimiento de lo que hicieron, en especial de lo que hicieron mal.

No suele ser el caso que yo me he encontrado: empresas que arrastran un códido hecho por una docena de programadores distintos, traídos por distintas consultoras, que estaban aprendiendo cuando lo escribieron, están ahora inaccesibles y no dejaron la más mínima documentación detrás. *Ése* es el pan nuestro de cada día (para servidor, YMMV).

Para mí la diferencia fundamental es si existe documentación suficiente. Pueden ser documentos externos, comentarios o conocimiento del negocio por alguna persona. Si la única documentación es el código y el código es malo, reescribir no es la solución.

Antes de matar al deshauciado hay que curarlo (refactorización, catalogación de accesos a BD y funcionalidad, cobertura SEH, documentación a posteriori, todo eso).

Claro que, una vez curado, no hay argumentos tan fuertes para reescribirlo, salvo el "ya nadie usa este lenguaje", que tampoco es un disparate, pero no es lo mismo que "hemos perdido el control del entorno".

Cuenta la leyenda que por re-escribir el código Netscape se fue al garete...

@marcis es lo que cuenta Joel Spolsky en el enlace que puse, sí :)