Joel on Software

Joel on Software   La Opinión de Joel sobre qué es Software

 

Otros artículos de "Joel on Software" en Español

Otros artículos de "Joel on Software" en Inglés

Envíele un Email al autor (solo en Inglés)

 

Cosas que Nunca se Deberían Hacer, Parte I


Por Joel Spolsky
Traducido por Pablo Camba Martínez
Editado por Miguel Cardo
6.4.2000

Netscape 6.0 está por fin en su primera beta pública. Nunca hubo una versión 5.0. La entrega principal, versión 4.0, fue publicada hace tres años. Tres años es un intervalo de tiempo terriblemente largo en el mundo de Internet. Durante este tiempo, Netscape estuvo quieto, sin poder hacer nada, viendo cómo su mercado caía en picado.

Es algo zalamero por mi parte criticarles por esperar tanto entre publicaciones. No lo hicieron a propósito, ¿o sí?

Bueno, sí. Lo hicieron. Lo hicieron cometiendo el peor error estratégico que una compañía de software puede cometer:

Decidieron reescribir el código desde cero.

Netscape no fue la primera compañía en cometer este error. Borland cometió el mismo error cuando compró Arago e intentó reconvertirla en dBase para Windows, un proyecto condenado al fracaso que llevó tanto tiempo que Microsoft Access se comió el pastel, luego lo volvieron a cometer al reescribir Quattro Pro desde cero y asombrando a la gente con qué pocas funciones tenía. Microsoft casi cometió el mismo error, intentando reescribir Word para Windows desde cero en un proyecto condenado al fracaso llamado Pyramid, el cual fue cerrado, desechado y barrido debajo de la alfombra. Afortunadamente para Microsoft, nunca habían dejado de trabajar en el viejo código fuente, así que tenían algo que entregar, haciendo que fuese simplemente un desastre económico, no un desastre estratégico.

Nosotros somos programadores. Los programadores son, en lo más profundo, arquitectos, y la primera cosa que quieren hacer cuando llegan a un sitio es nivelar el terreno a fuerza de bulldozers y construir algo magnífico. No nos gusta la renovación incremental: hacer pequeños ajustes, mejoras, sembrar parterres.

Hay siempre una sutil razón por la que los programadores siempre quieren desechar el código y empezar de nuevo. La razón es que piensan que el viejo código es una ruina. Y aquí está la observación interesante: probablemente están equivocados. La razón por la que piensan que el viejo código es una ruina es por una ley capital y fundamental de la programación:

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

Esta es la razón por la que reutilizar código es tan difícil. Esta es la razón por la que todo el mundo en tu equipo tiene una función diferente que le gusta usar para separar cadenas en arrays de cadenas. Escriben su propia función porque es más fácil y más divertido que adivinar cómo funciona la antigua función.

Como corolario de este axioma, puedes preguntar hoy a casi cualquier programador sobre el código sobre el que está trabajando.

“Es una ruina espeluznante” te contarán. “No hay nada que me gustaría más que tirarlo y empezar de nuevo”

¿Por qué es una ruina?

“Bien”, dice, “mira esta función. ¡Tiene dos páginas de longitud!.¡Ninguna de estas cosas pertenece a la función! No sé para qué son la mitad de estas llamadas a la API.”

Antes de que la nueva hoja de cálculo de Borland para Windows saliese al mercado, Philippe Kahn, el pintoresco fundador de Borland, fue citado en un montón de medios de comunicación alardeando cómo Quattro Pro sería mucho mejor que Microsoft Excel, porque estaba escrito desde cero. ¡Todo sería código fuente nuevo! Como si el código fuente se oxidase.

La idea de que el nuevo código es mejor que el viejo es a todas luces absurdo. El viejo código ha sido usado. Ha sido probado. Muchos bugs han sido encontrados, y han sido arreglados. No hay nada malo en ello. No adquiere bugs en el disco duro simplemente por estar ahí. ¡Al contrario, baby!. ¿Se supone que el software es como un viejo Dodge Dart, que se oxida simplemente estando en el garaje? ¿ Es el software como un osito de peluche que es de mala calidad si no está hecho todo de material nuevo?

De vuelta a la función de dos páginas. Sí, sé que es una simple función para mostrar una ventana, pero le han crecido pequeños pelos y cosas que nadie sabe por qué. Bien, te diré por qué: son bugs solucionados. Uno de ellos arregla el bug que Nancy tenía cuando intentaba instalar el programa en una computadora que no tenía Internet Explorer. El otro soluciona el bug que ocurre en condiciones de baja memoria. Otro arregla el bug que ocurría cuando el archivo está en un floppy disk y los usuarios sacan el disco a la mitad. Esa llamada a una librería de carga es fea pero hace que el código funcione en viejas versiones de Windows 95.

Cada uno de estos bugs llevó semanas de uso en trabajo real antes de que fuesen encontrados. El programador perdió probablemente un par de días reproduciendo el bug en el laboratorio y arreglándolo. Si se trata de un montón de bugs, el arreglo podría tratarse de una línea de código, o más aún, podría ser un par de caracteres, pero hay un montón de trabajo y tiempo invertido en ese par de caracteres.

Cuando desechas código y empiezas desde cero, estás desechando todo ese conocimiento. Todos aquellos arreglos de bugs. Años de trabajo de programación.

Te estás poniendo a ti mismo en una posición extremadamente peligrosa donde estarás entregando una vieja versión del código durante varios años, completamente incapaz de realizar cambios estratégicos o reaccionar ante las nuevas características que demanda el mercado, porque no tienes código que entregar. Lo mismo también podrías cerrar el negocio durante ese periodo de tiempo.

Estás desperdiciando una extravagante suma de dinero escribiendo código que ya existe.

¿Hay alguna alternativa? El consenso parece ser que el viejo código de Netscape era realmente malo. Bien, podría haber sido malo, sin embargo, ¿sabes una cosa? Funcionaba bastante bien en un muchísimos sistemas de computadoras en el mundo real.

Cuando los programadores dicen que su código es una gran ruina (como siempre hacen), hay tres clases de cosas en las que están equivocados.

Primero, hay problemas en la arquitectura. El código no está hecho correctamente. El código de red hace aparecer sus propias cajas de diálogo en medio de ninguna parte, esto debería de haber sido tratado en el código de la interfaz de usuario. Estos problemas pueden ser resueltos por un solo programador, de un solo golpe, moviendo código con cuidado y comprobando sus cambios de una sola vez, así nadie más se ve afectado. Incluso cambios importantes en la arquitectura pueden ser llevados a cabo sin desechar el código. En el proyecto Juno gastamos varios meses reformando la arquitectura en un solo punto: sólo moviendo las cosas, haciendo que quedasen claras, creando clases base que tuvieran sentido, y creando interfaces bien definidos entre los módulos. Pero lo hicimos con cuidado, con nuestro código base ya existente, y no introdujimos nuevos bugs o desechamos código que ya funcionaba.

Una segunda razón por la que los programadores piensan que su código es una ruina es que es ineficiente. Se decía que el código interpretado en Netscape era muy lento. Pero eso sólo afecta a una pequeña parte del proyecto, el cual puedes optimizar o incluso reescribir. No lo tienes que reescribir todo entero. Cuando optimizas para eficiencia, el 1% del esfuerzo hace que obtengas el 99% del resultado.

Tercero, el código puede ser muy feo. En un proyecto en el cual trabajé tenía un tipo de datos llamado JodidaCadena. Otro proyecto había empezado usando la convención de empezar los miembros de variables con un guión bajo, pero mas tarde cambiaron al más estándar “m_”. Así que la mitad de las funciones empezaban con “_” y la otra mitad con “m_”, lo que hacía que quedase muy feo. Francamente, esta es la clase de cosa que puedes resolver en cinco minutos con una macro de Emacs, no empezando desde cero.

Es importante recordar que cuando empiezas desde cero no hay absolutamente ninguna razón para creer que vas a hacer un trabajo mejor que el que hiciste la primera vez. En primer lugar, probablemente no sigas teniendo el mismo equipo de programación que trabajó en la versión uno, así que no tienes realmente “más experiencia”. Se van a volver a cometer la mayoría de los viejos errores, y se van a introducir algunos problemas nuevos que no estaban en la versión original.

El viejo mantra construye para desechar es peligroso cuando se refiere a aplicaciones comerciales a gran escala. Si estás escribiendo código experimentalmente, puedes querer hacer pedazos la función que escribiste la semana pasada al pensar en un algoritmo mejor. Eso está bien. Puedes querer rehacer una clase para hacer que su uso sea más sencillo. Eso también es bueno. Pero desechar todo el programa es un capricho peligroso, y si Netscape hubiera tenido realmente alguna supervisión adulta con experiencia en la industria del software, no se habrían disparado a sí mismos en el pie tan malamente.



Esté articulo apareció originalmente en Inglés con el nombre Things You Should Never Do  

Joel Spolsky es el fundador de Fog Creek Software, una pequeña empresa de software en Nueva York. Es titulado por la Universidad de Yale y ha trabajado como programador y gerente en Microsoft, Viacom, y Juno.


El contenido de estas páginas representan la opinión de una persona.
Todo el contenido es Copyright ©1999-2005  por Joel Spolsky. Todos los derechos son reservados.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky