Cosas que nunca deberías hacer, Parte I

From The Joel on Software Translation Project

Jump to: navigation, search

Por Joel Spolsky
Jueves 6 de Abril de 2000
Artículo original: [1]
Traducido originalmente por: Victor Rodriguez


Netscape 6.0 esta por fin yendo hacia su primera beta publica. Nunca hubo una versión 5.0. El ultimo lanzamiento, la versión 4.0, fue lanzada casi tres años atrás. Tres años es un tiempo horriblemente largo en el mundo de Internet. Durante este tiempo, Netscape se quedo sentada, sin poder hacer nada, mientras su porción del mercado se desplomaba.

Es algo insincero de mi parte el criticarlos por esperar tanto entre lanzamientos. Ellos no lo hicieron a propósito, ¿o si?

Bueno si, si lo hicieron. Lo hicieron al realizar el peor error estratégico simple que cualquier compañía de software puede hacer:

Ellos decidieron re-escribir el código desde cero.

Upper_West_Side_Brownstones_2.jpg

Netscape no fue la primera compañía en cometer este error. Borland cometió el mismo error cuando compraron Arago y trataron de convertirlo en dBase para Windows, un proyecto predestinado al fracaso que tomo tanto que Microsoft Access les comió el lunch, luego volvieron a equivocarse otra vez al re-escribir Quattro Pro desde cero y pasmar a la gente por tan pocas características que este tenia. Microsoft casi cometió el mismo error, tratando de re-escribir Word para Windows desde cero en un proyecto condenado a fracasar llamado Pyramid el cual fue cancelado, desechado y barrido debajo del tapete. Afortunadamente para Microsoft, ellos nunca dejaron de trabajar en la base de código antigua, de tal manera que tenían algo que comercializar, convirtiéndolo en simplemente un desastre financiero y no en uno estratégico.

Somos programadores. Los programadores son, en sus corazones, arquitectos, y la primera cosa que quieren hacer cuando llegan a un sitio es demoler la zona por completo y construir algo magnifico. No nos emociona la renovación incremental: remendar, mejorar, plantar lechos de flores.

Hay una razón sutil por la que los programadores siempre quieren desechar el código y empezar de nuevo. La razón es que ellos piensan que el código viejo es un enredo. Y he aquí una observación interesante: ellos probablemente están equivocados. La razón por la que ellos piensan que el el código antiguo es un enredo es a causa de un ley fundamental y cardinal de la programación:

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

Es por eso que la reutilización de código es tan difícil. Es por eso que cada persona en tu equipo tiene una función diferente que les gusta usar para separar cadenas en arreglos de cadenas. Ellos escriben su propia función porque es mas fácil y mas divertido que descifrar como funciona la función antigua.

Columbus_Ave_Barber_Shop.jpg

Como un corolario de este axioma, tu puedes preguntar hoy a casi cualquier programador acerca del código en el que están trabajando. "Es un enorme enredo peludo" te dirán. "Nada me gustaría mas que arrojarlo y empezar de nuevo"

¿Porque es un enredo?

"Bien,"ellos dirán, "mira esta función. abarca dos páginas! Nada de esto debería de estar aquí! Yo no se para que sirve la mitad de estas llamadas de la API"

Antes de que la nueva hoja de calculo de Borland fuera comercializada, Philippe Kahn, el pintoresco fundador de Borland, fue citado bastante en la prensa jactándose de como Quattro Pro sería mucho mejor que Microsoft Excel, porque fue escrito desde cero. Código fuente totalmente nuevo! Como si el código fuente enmoheciera.

La idea de que el código nuevo es mejor que el viejo es evidentemente absurda. El código viejo ha sido usado, ha sido probado, unamultitud de bugs han sido encontrados en el y han sido reparados, no hay nada de malo en el, no adquiere bugs solo por estar sentado sin moverse en tu disco duro. Au contraire, baby! ¿Se supone que el software es como un viejo Dodge Dart, que enmohece solo por estar estacionado en la cochera? ¿Es el software como un osito teddy que es repugnante si no esta hecho de materiales totalmente nuevos?

Volviendo a esa función de dos páginas, si lo se, es solo una simple función para desplegar una ventana, pero le han crecido pelitos y otras cosas encima y nadie sabe porque. Bueno, Yo te diré porque: esas son correcciones de bugs. Uno de ellos corrige aquel bug que Nancy tenia cuando intento instalar la cosa en una computadora que no tenia Internet Explorer. Otro de ellos corrige aquel bug que ocurre en condiciones de poca memoria. Otro mas arregla ese bug que ocurría cuando el archivo esta en un disco flexible y el usuario extrae el disco a medio camino. Esa llamada a LoadLibrary es fea pero hace que el código trabaje en versiones antiguas de Windows 95.

Cada uno de aquellos bugs tomo semanas de tiempo del mundo real antes de que fueran encontrados. El programador podría haber invertido un par de días re-produciendo el bug en el laboratorio y corrigiéndolo. Si este es como muchos bugs, la corrección podría ser una linea de código o podría ser incluso un par de caracteres, pero se invirtió bastante trabajo en esos dos caracteres.

Cuando tu desechas el código y empiezas desde cero, tu estas desechando todo ese conocimiento, todas aquellas correcciones de bugs acumuladas, años de trabajo de programación.

Estas desechando tu liderazgo de mercado. Le estas dando un obsequio de dos o tres años a tus competidores, y creeme, eso es un largo tiempo en años software.

Te estas poniendo a ti mismo en una posición extremadamente peligrosa donde estarás comercializando una versión vieja del código por varios años, totalmente incapaz de hacer ningún cambio estratégico o reaccionar a las nuevas características que exige el mercado, porque no tienes código comercializable. Bien podrías cerrar tu negocio durante ese tiempo.

Estas desperdiciando una cantidad estrafalaria de dinero escribiendo código que ya existe.

Columbus_Ave.jpg

¿Existe una alternativa? El consenso parece ser que la vieja base de código de Netscape era realmente mala. Bien, podría haber sido mala, pero sabes que? Trabajaba condenadamente bien en una tremenda cantidad de sistemas de computo del mundo real.

Cuando los programadores dicen que su código es un santo enredo (como siempre lo hacen), hay tres clases de cosas que están mal con eso.

Primero, hay problemas de arquitectura. El código no esta estructurado correctamente. El código de conexiones de red (networking) esta haciendo surgir sus propios cuadros de dialogo desde mitad de la nada; esto debió haber sido manejado en el código de interfaz de usuario (UI). Estos problemas pueden ser resueltos, uno a la vez, cuidadosamente moviendo el código, refactorizando, cambiando interfases. Esto puede ser realizado por un programador trabajando cuidadosamente y registrando (checking in) todos sus cambios juntos de una vez, de tal manera que nadie mas sea interrumpido. Incluso cambios de arquitectura bastante mayores pueden ser realizados sin desechar el código. En el proyecto Juno nosotros gastamos varios meses rehaciendo la arquitectura en un punto: solo moviendo cosas, limpiándolas, creando clases base que tuvieran sentido, y creando interfases finas entre los módulos. Pero lo hicimos cuidadosamente, con nuestro código base existente y no introducimos nuevos bugs o desechamos código que funciona.

Una segunda razón por la cual los programadores piensan que su código es un enredo es que es ineficiente. Se rumoraba que el código de renderización en Netscape era lento. Pero esto solamente afecta a una pequeña parte del proyecto, la cual puedes optimizar o incluso re-escribir. Tu no tienes que re-escribir todo. Cuando optimizas por velocidad, el 1% del trabajo te proporciona el 99% del impacto.

Tercero, el código podría ser condenadamente feo. Un proyecto en el que trabajé de hecho tenia un tipo de datos llamado JodidaCadena (FuckedString). Otro proyecto había arrancado usando la convención de comenzar las variables miembro con un guión bajo, pero después cambio al mas estándar: "m_". Así que la mitad de las funciones comenzaban con "_" y la mitad con "m_", lo cual se veía feo. Francamente, esta es la clase de cosa que resuelves en cinco minutos con una macro en Emacs, no comenzando desde cero.

Es importante recordar que cuando empiezas desde cero absolutamente no hay ninguna razón para creer que vas a hacer un mejor trabajo que el que hiciste la primera vez. Primero que nada, probablemente no tienes siquiera el mismo equipo de programación que trabajo en la versión uno, así que en realidad no tienes "mas experiencia". Simplemente vas a cometer la mayoría de los viejos errores otra vez, e introducir algunos nuevos problemas que no estaban en la versión original.

Lincoln_Center_Trees.jpg

La vieja mantra de construye uno para desechar es peligrosa cuando es aplicada a aplicaciones comerciales en escala grande. Si tu estas escribiendo código experimentalmente, podrías querer abrir la función que escribiste la semana pasada cuando se te ocurra un mejor algoritmo, eso esta bien. Puedes querer refactorizar una clase para hacerla mas fácil de usar. eso también esta bien. Pero desechar el programa entero es un disparate peligroso, y si Netscape de hecho hubiera tenido algo de supervisión de un adulto con experiencia en la industria del software, ellos podrían no haberse disparado en el pie tan gravemente.

Personal tools