Rudy Godoy :: an act of subversive playful cleverness

Hace unas semanas se ha publicado la actualización del Whitepaper «Software Development’s Classic Mistakes 2008» de la consultora Construx, que está disponible para descarga de manera gratuita.

Este trabajo de Steve McConnell, autor del libro «Rapid Development», recopila los errores más comunes en el proceso de desarrollo de software y tiene como objetivo el ofrecer un vistazo único a los factores de riesgo más comunes. Originalmente la lista se inició con 36 errores a partir de la publicación del libro en 1996, y a la fecha reune datos obtenidos del trabajo con más de 1000 clientes de Construx.

Entre las fuentes que han aportado para la elaboración de dicha actualización se encuentran Jefes o arquitectos de software (55%), gerentes (11%), Gerentes técnicos o con doble rol (6%), y técnicos (22%).

Entre los primeros 10 errores más frecuentes se identifico a los primeros 5 con el modo de «Casi siempre» y a los siguientes como «a menudo»:

1. Cronogramas demasiado optimistas
2. Expectativas irreales
3. Aseguramiento de calidad infimo
4. Oficinas ruidosas y hacinadas
5. Confusión de estimados con objetivos
6. Excesiva aplicación de multi-tarea
7. Pesadilla de características
8. Pensamiento iluso
9. Gestión de riesgo insuficiente
10. Omisión de tareas necesarias para estimados

Entre ellos se clasifico como de alto impacto con una criticidad de «Catastrófico» y «serio» en el siguiente orden.

1. Expectativas irreales (83%)
2. Personal inadecuado (78%)
3. Cronogramas demasiado optimistas (78%)
4. Pensamiento iluso (76%)
5. Aseguramiento de calidad infimo (72%)
6. Diseño inadecuado (72%)
7. Falta de auspicio del proyecto (71%)
8. Confusión de estimados con objetivos (71%)
9. Excesiva aplicación de multi-tarea (71%)
10. Falta de involucramiento del usuario (70%)

Es particularmente interesante observar que 35 de los 42 errores clásicos se clasificaron como de impacto catastrófico o serio por mas del 50% de participantes.

El paper ofrece además métrica de exposión al riesgo (RE) que mide la severidad y el impacto de forma aproximada, básicamente obtenida del producto de ambos criterios bajo la fórmula RE = severidad * impacto.

Una de las cosas que me llamo la atención fue el tema de «Whishful thinking» o pensamiento iluso, que ha sido calificado en la posición 4. A veces ocurre que en la gestión del proyecto se cierra totalmente en la idea de que va algo va a funcionar cuando no se tiene base concreta o razonable para pensar que así será. Costrux indica que esto puede llevar a grandes problemas si se da al inicio del proyecto, pero lo mas grave es que menoscaba el planeamiento adecuado y puede ser la raíz se otros problemas.

Como tantos de los temas en gestión de proyectos de diversa índole, este no deja de tener al factor humano como clave, fuera de buenas prácticas, métricas, procesos o metodologías, si el personal que lidera el proyecto se cierra bajo una visión irreal esta puede tener consecuencias serias para la organización.

El otro tema que me parece interesante es el multi-tarea excesivo. Generalmente se suele confundir al desarrollo de proyectos usando metodologías ágiles y etiquetarlos con cierta metodología, sin tomar en cuenta todos sus aspectos. El problema con el excesivo uso de multi-tarea es que, según los estudios, cada «switch» entre tareas puede tomar de 5 a 30 minutos de «para» de desarrollo mientras la persona cierra el flujo de trabajo de un proyecto y se inserta en otro.

Finalmente el tema del ambiente laboral resulta vital, ya que un entorno ruidoso o demasiado hacinado evita la concentración y el estado necesario que se requiere para trabajar y obtener altos niveles de productividad. Se ha determinado que los trabajadores que tienen oficinas silenciosas y privadas tienden a deempeñarse sinificativamente mejor que aquellos que ocupan cubículos o bahías ruidosas y demasiado hacinadas.

Recomiendo leer este trabajo si trabajas o te interesa el tema de desarrollo de software, en especial si estas a cargo de proyectos o su gestión.

Cuando Richard Stallman, graduado en física por la universidad de Harvard que trabajaba como programador del laboratorio de inteligencia artificial del MIT, decidió renunciar a éste para iniciar su trabajo con el proyecto GNU en donde define las bases de lo que hoy conocemos como software libre a través del manifiesto GNU, posteriormente formalizado en una licencia, que básicamente expone un esquema de trabajo y un modelo de licenciamiento.

Este esquema de trabajo intenta mantener la cultura hacker de aquellos años donde se daba un valor muy alto al compartir y a la colaboración, aspectos que él observo se estaban perdiendo y deseaba mantener. Es por esto que inicia el proyecto GNU bajo el precepto de desarrollar un sistema operativo desde cero bajo este modelo de manera que se cuente con un base sobre el cual desarrollar un sistema computacional que se mantenga bajos los preceptos enunciados y resguardados por la licencia GNU GPL.

Este hecho pues, no represento más que una determinación por seguir con un modelo que a su criterio tendría más beneficios frente a los otros que empezaban a aparecer en la industria. En ningún momento el proyecto tuvo como objetivo el innovar, desarrollar nuevas tecnologías, o servir de arma contra las grandes corporaciones o el sistema.

Durante los años siguientes este espíritu se ha mantenido tal cual, en diversas ocasiones Richard ha vuelto a reafirmar que el propósito no es hacer el mejor software o usar las técnicas más avanzadas de la computación. El objetivo es mucho más simple: tener software que se pueda copiar, modificar, compartir y distribuir libremente (léase sin restricción).

Por esto, el software libre representa sencillamente un modelo de licenciamiento que tiene detrás un esquema de trabajo particular. Ciertamente alguno de los aspectos de este esquema de trabajo han tenido y tienen un gran impacto en la propia industria de software, pero en otros no son más que réplicas de entornos o prácticas desarrolladas en los entornos académicos, en donde nació.

Por ende, si nos restringimos a los aspectos técnicos de la gran mayoría del software desarrollado bajo este modelo, está fuera de lugar calificar al software libre como “nueva tecnología”, “tecnología emergente”, u otros calificativos que hagan referencia de que esto es algo nuevo técnicamente, debido a que son aspectos totalmente distintos. Hablar de nueva tecnología queda fuera de lugar si vamos a mostrar a Linux, Apache, Firefox, etc. que son proyectos que replican algo ya existente: un sistema operativo, un servidor web, un navegador web. Ninguno de estos ha sido innovador ni mucho menos emergente, como si lo fue por ejemplo el primer navegador web Mosaic, desarrollado (como dice su autor Marc Andreesen) como un proyecto “renegado” de investigación académica.

Por el otro aspecto, que tiene más que ver con valores y sociedad, y en donde algunas personas parecen haber encontrado el eslabón perdido al etiquetarlo como “filosófico” para usarlo como trampolín para propalar sus propias ideas políticas, tampoco se tiene como objetivo el realizar dichas actividades o propalar mensajes de cierta índole. Desde la existencia de la humanidad el acto de compartir ha sido una práctica valorada y que ha sido esencial para la subsistencia de la misma. Asimismo, las prácticas que están relacionadas con el proceso de desarrollo de software son en gran medida aplicación de trabajos desarrollados en el entorno académico.

Sin embargo, lo que ha hecho el software libre y el movimiento FLOSS es ponerlas en práctica, hacer evidente que se puede hacer cosas interesantes bajo este modelo, ha hecho voltear los ojos a la industria de software, a las empresas, a la sociedad. Hoy no existe alguna actividad que haya acogido alguna de las prácticas generalizadas como “opensource” dentro de su propio trabajo, desde Wikipedia, las comunidades de eR&D, el modelo de las aplicaciones 2.0, las empresas, los políticos, etc. Hoy se habla de Enterprise 2.0, Politica 2.0, eGov 2.0, y tal. Hoy podemos decir que este 2.0 tiene un 1.5 de ingredientes gracias al software libre.

Un modelo de licenciamiento, junto a un esquema de trabajo han hecho esto posible. Es por eso que personalmente es un orgullo formar parte de su desarrollo y aportar algo a la sociedad del futuro. Y es la misma motivación que me llevo a involucrarme en esto luego de leer el manifesto GNU hace algo más de 10 años, sólo eso, nada más.

Cada uno de los otros temas se desarrollan en su propio entorno por quienes tiene interés en hacerlo, no hay que mezclar las cosas. Siempre es bueno volver revisar los fundamentos sobre lo que se construye algo.