Siguiente Anterior Indice 

5. ¿Cuando una rosa deja de serlo?

Tras estudiar el comportamiento de Linus y desarrollar una teoría sobre los motivos de su éxito, decidí conscientemente comprobar su validez sobre mi nuevo (desde luego mucho menos complejo y ambicioso) proyecto.

Pero lo primero que hice fue reorganizar y simplificar 'popclient' en buena medida. La implementación de Carl Harris era muy brillante, pero mostraba cierta complejidad innecesaria bastante generalizada entre muchos programadores en C. Trataba el código como la parte más importante y las estructuras de datos como un mero apoyo. Como resultado, el código era magnífico pero las estructuras de datos se habían diseñado con descuido y resultaban bastante espantosas (al menos para los severos criterios impuestos por el antiguo 'hacker' en Lisp que les está narrando esto).

Por si no bastara, tenía otro propósito en mente para reescribirlo además de mejorar el código y el diseño de las estructuras de datos. Consistía en conducirlo a algo que yo entendiera por completo. No es divertido ser el responsable de la depuración de un programa que no comprendes.

Por tanto, más o menos durante el primer mes, me limité a aceptar las consecuencias derivadas del diseño original de Carl Harris. El primer cambio importante que hice fue añadir soporte para 'IMAP'. Para ello reorganicé los módulos relacionados con la gestión de protocolos (para POP2, POP3 e IMAP) convirtiéndolos en un controlador genérico y tres tablas para los métodos de gestión. Esto, y los cambios anteriores, ilustran un principio general que conviene tener en mente, especialmente en lenguajes que, como C, no conducen de forma natural al concepto de estructuras de datos dinámicas:

9. Estructuras de datos inteligentes asociadas a un código torpe funcionan mucho mejor que la alternativa opuesta.

Otra vez Fred Brooks, en el Capítulo 11: "Enséñame tu código y mantén ocultas tus estructuras de datos, y me seguirás engañando. Muéstrame tus estructuras de datos y normalmente no necesitaré que me enseñes tu código: resultará evidente."

En realidad, él decía "organigramas" y "tablas". Pero pasándolo por el filtro de treinta años de terminología y evolución cultural, viene a ser lo mismo.

En este momento (a principios de Septiembre de 1996, unos seis meses después de haber empezado) empecé a pesar en la conveniencia de un cambio de nombre -- al fin y al cabo, ya no era sólo un cliente POP. Pero dudaba, pues todavía no había nada realmente nuevo en el diseño. Mi versión de 'popclien' aún tenía que desarrollar su propia personalidad.

La situación cambió radicalmente cuando 'fetchmail' aprendió a enviar el correo recogido a una puerta SMTP. Pronto veremos eso. Pero, en primer lugar, ocupémonos de lo siguiente: dije antes que decidí usar este proyecto para poner a prueba mi teoría sobre qué había hecho bien Linus Torvalds. Puedes estarte preguntando ¿cómo lo llevé a cabo?. De las siguientes maneras:

  1. Lancé versiones pronto y con frecuencia (casi nunca menos de una versión cada diez días y, en periodos de desarrollo intenso, una diaria).
  2. Hice crecer mi lista de probadores de las versiones beta añadiendo a ella a todo aquel que se puso en contacto conmigo interesándose por 'fetchmail'.
  3. Envié anuncios seductores a la lista de personas incluidas en la prueba de las betas siempre que lancé una nueva versión, animando a la gente a que participara.
  4. Y escuché lo que ellos tuvieron que decir, manteniéndoles al corriente de las decisiones tomadas sobre el diseño y agradeciendo su colaboración siempre que enviaban correcciones o informes sobre el funcionamieno del programa.
La recompensa obtenida a cambio de acciones tan sencillas fue inmediata. Desde que el proyectó comenzó, dispuse de informes sobre errores de una calidad tal que la mayoría de los desarrolladores matarían a alguien por conseguirla, a menudo con correcciones propuestas para solucionarlos. Logré críticas razonadas, conseguí correo animándome a proseguir, me llegaron un montón de sugerencias sobre cosas a añadir. Lo que nos lleva a proponer que:

10. Si tratas a la gente que te ayuda a depurar un programa como si fueran tu recurso más valioso, responderán convirtiéndose en eso precisamente.

Una forma interesante de medir el éxito de 'fetchmail' consiste simplemente en mirar el tamaño de la lista de personas que participaron en las pruebas en la fase beta del desarrollo, de los que apoyaron 'fetchmail'. Cuando escribo esto, tiene 249 miembros y sigue creciendo al ritmo de dos o tres por semana.

De hecho, al revisar esto a principios de Mayo de 1997, la lista está perdiendo miembros por una razón interesante. Algunos me han pedido que los retire de ella por cuanto 'fetchmail' les funciona tan bien ¡que no necesitan seguir ya su evolución!. Quizá esta sea la forma natural en que evoluciona un proyecto maduro en el estilo bazar.


Siguiente Anterior Indice