2008-07-08 00:13:37

Leer el libro en espa�ol: http://biblioweb.sindominio.net/telematica/catedral.html

Analizo un exitoso proyecto de software libre (fetchmail), que fue realizado para probar deliberadamente algunas sorprendentes ideas sobre la ingenier�a de software sugeridas por la historia de Linux. Discuto estas teor�as en t�rminos de dos estilos de desarrollo fundamentalmente opuestos: el modelo catedral de la mayor�a de los fabricantes de softaware comercial contra el modelo bazar del mundo Linux. Demuestro que estos modelos parten de puntos de vista contrapuestos acerca de la naturaleza de la tarea de depuraci�n del software. Posteriormente, hago una argumentaci�n, a partir de la experiencia de Linux, de la siguiente sentencia: «si se tienen las miradas suficientes, todas las pulgas saltar�n a la vista''. Al final, sugiero algunas fruct�feras analog�as con otros sistemas autoregulados de agentes egoistas, y concluyo con una somera exploraci�n de las implicaciones que pude tener este enfoque en el futuro del software.

Lecciones enumeradas en La Catedral y el Bazar de Eric S. Raymond

Desde Wikipedia: http://es.wikipedia.org/wiki/La_Catedral_y_el_Bazar

Todo buen trabajo de software comienza a partir de las necesidades personales del programador. (Todo buen trabajo empieza cuando uno tiene que rascarse su propia comez�n)

2. Los buenos programadores saben qu� escribir. Los mejores, qu� reescribir (y reutilizar).
3. «Considere desecharlo; de todos modos tendr� que hacerlo.» (Fred Brooks, The Mythical Man-Month, Cap�tulo 11)
4. Si tienes la actitud adecuada, encontrar�s problemas interesantes.
5. Cuando se pierde el inter�s en un programa, el �ltimo deber es heredarlo a un sucesor competente.
6. Tratar a los usuarios como colaboradores es la forma m�s apropiada de mejorar el c�digo, y la m�s efectiva de depurarlo.
7. Libere r�pido y a menudo, y escuche a sus clientes.
8. Dada una base suficiente de desarrolladores asistentes y beta-testers, casi cualquier problema puede ser caracterizado r�pidamente, y su soluci�n ser obvia al menos para alguien. O, dicho de manera menos formal, «con muchas miradas, todos los errores saltar�n a la vista». A esto lo he bautizado como la Ley de Linus.
9. Las estructuras de datos inteligentes y el c�digo burdo funcionan mucho mejor que en el caso inverso.

Si usted trata a sus analistas (beta-testers) como si fueran su recurso m�s valioso, ellos le responder�n convirti�ndose en su recurso m�s valioso.
Lo mejor despu�s de tener buenas ideas es reconocer las buenas ideas de sus usuarios. Esto �ltimo es a veces lo mejor.
Frecuentemente, las soluciones m�s innovadoras y espectaculares provienen de comprender que la concepci�n del problema era err�nea.
«La perfecci�n (en dise�o) se alcanza no cuando ya no hay nada que agregar, sino cuando ya no hay nada que quitar.»
Toda herramienta es �til emple�ndose de la forma prevista, pero una *gran* herramienta es la que se presta a ser utilizada de la manera menos esperada.
Cu�ndo se escribe software para una puerta de enlace de cualquier tipo, hay que tomar la precauci�n de alterar el flujo de datos lo menos posible, y �*nunca* eliminar informaci�n a menos que los receptores obliguen a hacerlo!
Cuando su lenguaje est� lejos de un Turing completo, entonces el az�car sint�ctico puede ser su amigo.
Un sistema de seguridad es tan seguro como secreto. Cu�dese de los secretos a medias.
Para resolver un problema interesante, comience por encontrar un problema que le resulte interesante.
Si el coordinador de desarrollo tiene un medio al menos tan bueno como lo es Internet, y sabe dirigir sin coerci�n, muchas cabezas ser�n, inevitablemente, mejor que una.

2008-07-08 00:00:10

edited by JuananRuiz

WikiJuanan - LaCatedralYElBazar

2008-07-08 00:13:37

Lecciones enumeradas en La Catedral y el Bazar de Eric S. Raymond

2008-07-08 00:00:10