“The Cathedral and the Bazaar: Musings on Linux and Open Source” (presentado en el 97 y convertido en libro en el 99) de Eric S. Raymond está basado en las observaciones del proceso de desarrollo del kernel de Linux y en otras experiencias dirigiendo proyectos de código abierto. Y repasa la lucha entre el top-down y bottom-up, ya sabes, el bien y el mal, el yin y yang, tigres o leones, etc.
Esencialmente, el ensayo, y el posterior libro, contrasta dos modelos de desarrollo software diferentes, que si estás en este mundillo cuando ahora los leas te van a sonar (salvo que seas ya muy friki de esto y ya te hubieses leído el libro) y pensarás… “-Anda, pero…, pero si esto que decía este hombre (97) es de lo que se habla ahora (2015) mucho, hacer lo que dice este hombre se dice ahora que es ágil y… ¿ya lo decía este hombre en el 97?-“, y que resumidamente vino a plantear así, que hay dos maneras de enfrentar un desarrollo:
a) El modelo de la catedral, en el que el código fuente está disponible de versión en versión software, las versiones salen de muchos meses en muchos meses y mientras las ven sólo un exclusivo grupo de desarrolladores de software. Manera de trabajar que relaciona con el modelo en cascada.
b) El modelo Bazar, en el que se desarrolla el código a través de Internet, a la vista del público, con lo que con mayor frecuencia el desarrollo está expuesto a mucha más gente y que, derivándolo al popular modelo “cloud” vendría a ser que la versión está constantemente expuesta muchos usuarios. Raymond acredita a Linus Torvalds como el inventor de este proceso (yo creo que de esto se lleva hablando, con algunas diferencias, desde los 50, pero bueno). Manera de trabajar que relaciona con el “entrega una versión pronto y entrega frecuentemente”, que hoy algunos llamarán continuous delivery, deployment, etc.
«Dame suficientes ojos y todos los errores serán superficiales»
Más allá de los anteriores, aunque derivado, otra de las tesis centrales del libro, que además es de las que más populares le hicieron, fue la proposición de dame «suficientes ojos y todos los errores serán superficiales».
Lo anterior se basa en algo lógico: cuanto más gente vea el código, o la versión, más rápidamente los errores (o mejoras) serán descubiertos. Por el contrario, en el modelo Catedral se gasta demasiado tiempo en detectar los problemas, ya que la versión está disponible sólo a unos pocos desarrolladores (usuarios).
Un aporte más del libro, las lecciones de desarrollar open source.
Otra popular sección del libro son varias lecciones aprendidas. Son muchas, pero te he querido dejar las que a mí más me gustan:
Los buenos programadores saben qué escribir. Los grandes saben qué reescribir (y qué reutilizar).
Tratar a los usuarios como co-desarrolladores es la ruta menos problemática para mejorar el código rápidamente y eliminar errores de manera efectiva.
Entrega una versión pronto y entrega frecuentemente. Y escucha a tus clientes.
Lo más parecido a tener buenas ideas es reconocer las buenas ideas de tus usuarios.
La perfección(en el diseño) no se alcanza cuando no hay nada más que añadir… sino cuando no hay nada más para quitar.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024