klondike

Nos ha pasado a todos: llega un momento en que nos parece que todo el código que llevamos escrito es malísimo y que lo mejor que podemos hacer es empezar todo de nuevo. Suele ocurrir cuando el proyecto ya está casi maduro y por alguna razón debemos volver sobre algo escrito hace algún tiempo.
Me encontré esta idea en Joel on Software y por supuesto pensé: ¡Esto es lo que me pasa a mí! Y me huelo que es una sensación que ha tenido todo el que se haya dedicado alguna vez a picar código.
De repente, todo parece estar mal planteado y nos parece que cualquier intento de sortear los problemas sólo llevará a parchear el código, haciéndolo cada vez más confuso y poco elegante. La única solución posible parece desechar lo escrito y empezar el proyecto de cero.

Bien, si alguna vez has tenido esta clase de pensamientos, el mensaje es claro: ¡No cedas!

La mayoría de las veces, por supuesto, una decisión tan drástica no está justificada. Joel Spolsky da varios motivos que explican este curioso síndrome, de entre ellos, el que más me gusta es ese que dice:

Es mas difícil leer código que escribirlo.

Y esto explica muchas cosas. ¿Será por eso que siempre me parece peor el código que escribí hace unos meses que el que podría hacer ahora? Si mirando hacia atrás algunas decisiones que tomé me parecen erróneas, ¿No será que esa era la única forma práctica de hacer las cosas? ¿Puede ser que no esté comprendiendo a fondo lo que hace mi propio código o cómo lo hace?

En general la idea de que el código anterior es un bodrio y que ahora podríamos hacerlo mucho mejor no es más que un espejismo. Pero lo cierto es que está ilusión nos ha engañado a todos alguna vez, a mi se me ocurren más razones para explicarlo:

- Afán de perfeccionismo, una bestia muy peligrosa si no la sabes mantener a raya.

- A medida que avanzamos conocemos mejor los problemas a los que nos enfrentamos, tenemos una guía que nos permite saber qué cambios en el planteamiento van a solucionar los persistentes problemas que padeceremos después. Algo parecido a volver atrás una jugada de ajedrez, una vez que se conocen sus consecuencias. Vaya, esto no suena tan mal. Después de todo, igual no es tan mala idea reescribirlo todo de nuevo.
Alto ahí ¡No cedas!
Al menos, no cedas fácilmente. Y si después de todo estás convencido de que hay que cambiar algún aspecto esencial del programa, adelante, pero salva siempre todo lo posible, sé conservador. Siguiendo con el ejemplo del ajedrez, no es lo mismo volver atrás una jugada que retroceder hasta la posición inicial. Haciendo eso probablemente nunca se termine una partida.

- Es posible que te haya tocado ser analista, diseñador, programador y probador del proyecto, y hasta que tengas que encargarte de la atención al cliente. Y además, puede ser que te estén presionando para acabar el trabajo lo antes posible. Amenazado por plazos absurdos y acosado por los jefes es más que posible que algunas decisiones fundamentales sean erróneas o superficiales, y que comprometan todo el proyecto. En un caso así lo mejor que se puede hacer realmente es desechar todo lo escrito, quemar las naves y empezar de nuevo.
De todas formas, y antes de ceder a la tentación, como última barrera nos podemos acoger al conocido axioma:
Si funciona no lo toques
(Después de todo, ellos se lo han buscado ...)