Historias
Slashboxes
Comentarios
 

Una generación perdida en el bazar

editada por Drizzt el Martes, 21 Agosto de 2012, 22:36h   Printer-friendly   Email story
desde el dept. diseño-o-caos
(vía Reddit.programming) Leía hace un par de días el artículo A Generation Lost in the Bazaar de Poul Henning Kamp sobre el modelo de desarrollo del bazar descrito por Eric S. Raymon en la Catedral y el Bazar. El autor del artículo rechaza la filosofía de "just hack it" , prefiriendo una donde el diseño y la planificación del software (la vieja catedral) tienen mucha más importancia,dando da lugar a un software de más calidad. Para Poul toda la era de la burbuja de las .com fue un desastre para la calidad del software en general y para Unix en particular, y que la calidad de un software depende de que haya alguien encargado de la misma.

Mostrar opciones Umbral:
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.
  • por Drizzt (39) el Martes, 21 Agosto de 2012, 22:59h (#1318200)
    ( http://icewinddale.blogspot.com/ | Última bitácora: Martes, 24 Abril de 2012, 17:13h )
    Por completar la historia, Paul parte del libro The Design of Design: Essays from a Computer Scientist [amazon.com] para hacer sus afirmaciones. Respecto al artículo que he enlazado:
    • Comparto con Poul las críticas a las libtool y a todo el sistema de autoconf. He vivido hace poco el inicio de un proyecto donde decidimos usarlos y soy consciente del problema que tienen. Tengo otro proyecto que con un simple Makefile es capaz de compilar en MacOS X, Linux y Solaris - porque no he probado nada más. qmail era capaz de compilarse en multitud de sistemas, sin necesidad de scripts de configuración de cientos de miles de líneas.
    • Aunque hay proyectos que parecen que se desarrollan en el bazar, tienen personas encargadas de diseño , pruebas y controles de calidad. El kernel de Linux es un ejemplo claro, probablemente las Qt también. Muchos podréis poner otros ejemplos.
    • No sé si a día de hoy , sigue existiendo esa filosofía de era de las .com de hacer integraciones y refritos con soft libre cogidas con alfileres. Cada cual en su trabajo podrá contar una historia.
    --

    -- icewinddale.blogspot.com [blogspot.com]

    [ Responder ]
  • Pues no sé yo...

    (Puntos:3, Interesante)
    por papiBD (26562) el Martes, 21 Agosto de 2012, 23:08h (#1318202)
    ( Última bitácora: Domingo, 09 Agosto de 2009, 21:16h )
    Yo no soy de ese mundo, pero por lo que he oído lo más molón son las metodologías ágiles, las reuniones ultrarrápidas de diez minutos al empezar el día... Eso es una adaptación para pasar el modelo bazar al de catedral. La orientación del proyecto estará más definida, habrá más reparto de tareas que contribuciones pero los métodos han calado.

    Ni sí ni no, sino todo lo contrario.
    [ Responder ]
  • No estoy de acuerdo...

    (Puntos:3, Inspirado)
    por MaGaO (6286) <{magao} {at} {bigfoot.com}> el Miércoles, 22 Agosto de 2012, 00:34h (#1318207)
    ( http://barrapunto.com/ | Última bitácora: Viernes, 17 Agosto de 2012, 11:58h )
    Me intriga que alguien que ha estado en el proyecto FreeBSD haya olvidado que UNIX, precisamente, creció alrededor del concepto de programas pequeños, que hacían una cosa y la hacían bien. Me sorprende que haya dejado a un lado los "beneficios" del diseño en catedral que provocaron en su momento que menos del 50% de los proyectos encargados por el DoD estadounidense se llegara a terminar (y no hablemos ya de cumplir requisitos). Y me desconcierta que asocie la burbuja puntocom al concepto de bazar como razón para la supuesta pérdida de calidad del software.

    La calidad del software no es función del modelo catedral o bazar: tanto uno como otro han dado lugar a buenos y malos productos (¿olvida alguien que el servidor web Apache se llama así porque era "a patchy server", esto es un montón de parches aplicados sobre el httpd original?). Ninguno de estos modelos es "la solución" porque el desarrollo de software tiene muchos más componentes que la arquitectura de diseño: desde la obtención de requisitos hasta los procedimientos de prueba hay pasos que pueden deteriorar (y deterioran) la calidad del software.

    Y que no se confunda nadie: tener un "único responsable" funciona si el responsable es bueno y los que supervisa también lo son. El resto del tiempo sólo sirve para echar las culpas (con más o menos razón) a alguien en vez de buscar cómo resolver el problema. Igualmente, la burbuja puntocom dio lugar a muchos abusos... como cualquier otra burbuja. La diferencia es que no se cayeron puentes ni edificios por aluminosis.

    El ejemplo más evidente lo pone el propio autor: cualquiera puede escribir código, igual que cualquiera puede serrar cuatro tablas y hacer una estantería. El valor de ese código (o de esa estantería) vendrá dado por lo bien o mal que cumpla sus requisitos. Y eso es así lo haga un carpintero de tienda de toda la vida o lo diseñe un ingeniero para IKEA.

    En resumen, reutilizando parte de uno de los comentarios en el propio artículo: reutilizar el código es bueno; usar herramientas abstrusas lleva al copia-pega (que es malo); la complejidad excesiva es mala. Todo lo demás es despotricar por despotricar, mirando al pasado con unas gafas que no son de cristal rosa, son de plástico rosa opaco.

    --
    Marcos (cualquier parecido con la coincidencia es pura realidad)
    [ Responder ]
  • El Bazar estan en el Diseño

    (Puntos:1, Interesante)
    por pobrecito hablador el Miércoles, 22 Agosto de 2012, 07:12h (#1318217)
    Si una cosa me ha enseñado la experiencia practica de sacar proyectos adelante es que muy frecuentemente el bazar es el diseño en si.

    ¿Porque sucede esto? Un software tiene un uso directo, igual que lo tiene cualquier cosa física, sin embargo el diseño no son más que los planos. Los planos están escritos en papel (o en bits), pero no tienen uso directo. La importancia del uso directo es que aparece un validador que es el mundo físico. Mientras que un programa se ejecuta y vemos las consecuencias de lo que hemos hecho, eso no suele pasar en el diseño.

    Un amigo mio suele decir: "el papel lo aguanta todo". Si bien no es completamente cierto, por ejemplo si escribimos que una funcionalidad es que las bicis han de volar nos chirrían los ojos, si que es cierto que hay otros fallos que no son evidentes y casi en un primer momento pueden parecer completamente validos. Y ese es solo el primer paso, porque hay problemas derivados: sobre papel cada uno entiende lo que quiere (o lo que puede), no se puede especificar todo (sino tendríamos el software por el mismo precio) ... [y me dejo de lado que el cliente no sabe lo que quiere, aun menos quiere leer documentos técnicos, hace cambiar todo cuando lo tiene delante...]

    Así que considero importante la elaboración del software como parte del diseño. El software se ha de aguantar por si mismo, se valida contra el mundo real, todo el mundo percibe las consecuencias de las funcionalidades de la misma manera, no deja lugar a ambigüedades, ... Sin embargo la contra, es que sin una correcta planificación se puede perder mucho tiempo en "refactoring".

    ¿Cual es mi estrategia? Dualidad de opciones. Empezar por una planificación sencilla a muy alto nivel, dividir las partes mas esenciales y dar un nivel mínimo de detalle. Llegado a ese punto establecer unos objetivos muy específicos poco ambiciosos y empezar un ciclo de "prototipaje". Una vez acabado se puede volver a la planificación (si es que no se ha ido combinando), pero ya se tienen cosas físicas que se aguantan por si mismas.

    La gracia del asunto, es que el software en si mismo es también papel, salvo que es un papel especial que se aguanta, y en ciertos niveles de detalle, casi tiene el mismo coste hacer un texto en papel inservible que un texto en papel autoejecutable. Creo que quien asegura algo con absoluta certeza se equivoca y que frecuentemente la buena solución suele estar en un balance adecuado.
    [ Responder ]
  • La bendición de la catedral ...

    (Puntos:1, Interesante)
    por pobrecito hablador el Miércoles, 22 Agosto de 2012, 10:02h (#1318233)
    La bendición de la catedral es también su maldición. Y es ni más ni menos eso que llaman competitividad. La competitividad inicialmente es buena, ayuda a crear mejor software, a innovar. Pero a la larga termina en un mal endémico llamado versionitis. Esa necesidad constante de vender más y más licencias lanzando al mercado nuevas versiones no necesarias que nadie ha solicitado con opciones que raramente se utilizan. Y todo eso ocupando cada vez más memoria, más disco duro y más recursos de procesador. ¿Qué será lo siguiente?, ¿Harán bailar los iconos el chiqui chiqui?. Una vez un neoliberal me dijo que la versionitis era keynesianismo disfrazado pues es como la falacia de la ventana rota. Si todo el mundo se cambia a la última versión de work entonces yo no puedo leer documentos de otros y es como si me hubieran roto una ventana.

    Pero el bazar ha caído en la misma trampa de la versionitis. Creo recordar que hubo una versión de KDE que funcionaba muy bien, ¿Y si funcionaba bien para qué narices lo tocan?, ¿para romperlo?, ¿y qué pasó con gnome?, ¡Lo han roto también!.

    Hay una especie de leyenda urbana en el mundo informático que dice que un software nunca está acabado por que siempre se puede mejorar. Eso es totalmente falso. Cuando un software hace lo que debe de hacer, y lo hace bien, durante un periodo inicial de dos o tres años se manifiestan el 90% de los bugs y si esos bugs se resuelven sin regresiones, con el paso de los años los bugs serán cada vez más raros y tendremos un software muy fiable con mucha solera. Una aplicación muy depurada no debería necesitar de apenas mantenimiento, simplemente se descarga y se usa, otra cosa es que tenga dependencia de cosas que están cambiando continuamente.

    El problema tanto de la catedral como del bazar es que no siguen el principio "Si funciona no lo toques que se rompe", y en ocasiones no sólo rompen si no que hacen guarrerías como el nuevo sistema de menúes de Microsoft donde incluso el mismísimo Paint es inusable.
    Si cambiamos constantemente un software metiendo cosas raras que nadie necesita lo único que conseguimos es romperlo. Y eso es más grave incluso con cosas como KDE o gnome, donde rompen constantemente aplicaciones que dependen de esos entornos, obligando a sus desarrolladores a actualizar a la última versión.

    El bazar no es inferior a la catedral por que supuestamente no hagan ingeniería pero si adoptan las malas costumbres de la catedral no tendrán ninguna ventaja respecto a esta.
    [ Responder ]
  • por ignacio.agullo (49316) el Miércoles, 22 Agosto de 2012, 11:43h (#1318247)
    Lo de los modelos de desarrollo es como la política: siempre hay debate entre varias posturas. El bazar tiene sus fallos, pero no se pueden negar sus logros. Descalificar el bazar con argumentos de poco peso como exceso de enlaces entre bibliotecas suena a agarrarse a cualquier cosa. Y parafrasear la canción American Pie [wikipedia.org] para decir que se ha perdido una generación es caer en la descalificación, como un dinosaurio incapaz de adaptarse a nuevos modelos de desarrollo.
    [ Responder ]
  • Re:Mas FUD ?

    (Puntos:2)
    por svalk (4919) el Viernes, 24 Agosto de 2012, 01:00h (#1318420)
    ( Última bitácora: Domingo, 12 Agosto de 2012, 16:58h )
    usar palabras del diccionario incrementa la inseguridad
  • 5 respuestas por debajo de tu umbral de lectura actual.