El cazador del hombre-lobo (sin bala de plata)

 Aunque  la mayoría lo ignora, los que lo conocemos bien sabemos que Frederick Brooks, Jr. es el más sorprendente visionario de la industria del software. Su capacidad de análisis lo hizo poder imaginar tendencias con más de una década de anticipación. Sin haber asistido a la masificación de las PC’s y a la explosión de Internet. Vale la pena revisar lo que pensaba en los ’80 este padre de la evangelización. Reproduzco algunos pasajes de su artículo No hay bala de plata: Escencia y Accidentes de la Ingeniería de Software (1986)
 

 
Brooks compara a los proyectos informáticos con el hombre lobo porque los proyectos informáticos comienzan siendo criaturas inocentes, conocidas, familiares de nosotros mismos. Inesperadamente se transforman en pesadillas de calendarios incumplidos, presupuestos dilapidados y productos dañados
 
Con escepticismo pero sin pesimismo (sic), Brooks concluye que en décadas no hubo desarrollo, sea por apoyarse en una tecnología dada, sea por usar una técnica de administración, que garantizara mejoras en productividad, en simplicidad o en confiabilidad
 
Creo que la parte más compleja de construir software es la especificación, diseño y prueba del modelo conceptual, más que la labor de representar el modelo y testear la representación
 
Entonces consideró cuatro propiedades inherentes a la escencia del software
  • Complejidad. Los problemas clásicos de desarrollar software derivan de esta escencia. Casos típicos: dificultades de comunicación entre los miembros, lo que conlleva a productos fallados, costos desbordados y demoras en calendario. También puede darse por dificultades de enumerar los distintos estados de la aplicación, lo que conlleva a falta de confiabilidad. Dificultades en invocar funcionalidades, que decantan en aplicaciones difíciles de usar. Dificultades en extender la aplicación sin crear efectos colaterales
  • Conformidad. En cualquier caso deberá ser el software el que se deba adaptar al entorno y nunca al revés. A veces le toca por haber sido el último en llegar (los procesos existen primero, luego viene su automatización). Conformidad también porque debe cumplir con ciertas interfaces (de usuario, de otras aplicaciones)
  • Mutabilidad. El software siempre va a estar sujeto a cambios, mucho más que los objetos del mundo real. En gran medida por tratarse de piezas intangibles, fáciles de destruir y reconstruir nuevamente (al menos más fácil que probar hacerlo con casas, autos y otros tipos de construcciones). Pero más aún por la presión del usuario, que en cuanto se sienta cómodo con un software que le sea útil, no va a demorar mucho en imaginar (y pedir) nuevas formas en que ese software lo pueda ayudar
  • Invisibilidad. El software es invisible e individualizable en el espacio. Poder representar al software como una abstracción geométrica sería fabuloso. Pero en los hechos no es uno sino varios los diagramas que deben ser usados para representar, flujos de control, de datos, secuencias temporales, etc. Estos grafos no son planares ni jerarquicos entre sí. El software se intuye pero no se ve

Además de estas propiedades escenciales (inherentes a la naturaleza del software), Brooks -basándose en Aristóteles- considera también otras dificultades accidentales: existen dada la forma actual de construir software, pero no son inherentes

  • Lenguajes de alto nivel. Estas abstracciones conceptuales (operaciones, tipos de datos, secuencias, comunicaciones) tratan de aproximarse a la forma intelectual en que el usuario resuelve problemas. Con eso esconden la complejidad accidental del programa compilado, consistente en bits, registros, condiciones, bifurcaciones, canales, discos, interrupciones, etc
  • Tiempo compartido. La posibilidad de compartir el tiempo de ejecución entre procesos combate el accidente de los programas batch que se ejecutan en forma lenta y mejora la sensación de tiempo de respuesta general
  • Entornos de programación unificados. Aquí el autor hace referencia a entornos de programación como el de Unix, que con bibliotecas integradas, formatos de archivos unificados, tuberías y filtros combaten el accidente de tener aplicaciones que resuelven en forma individual las problemáticas comunes (reinventando superflua y peligrosamente la rueda). Es interesante ver la evolución que han tenido en estos últimos años plataformas como .NET o JEE, ambas fundadas en API’s de bajo nivel que, combinadas, otorgan una potencia sin precedentes. Brooks ya lo había insinuado antes
Entonces el autor comienza a enumerar intentos por forjar la bala de plata, en una forma esperanzadora confiando en que con el tiempo se logrará aproximarla
  • Programación Orientada a Objetos. Si bien manifiesta tener más esperanzas en este paradigma que en ninguna otra cosa de hoy en día (el artículo es de 1986!), admite que con la abstracción y la jerarquización sólo ataca el accidente de tener enormes expresiones sintácticas. No obstante la complejidad de los diseños no es accidental sino escencial
  • Sistemas Expertos. Brooks encuentra útiles estos sistemas basados en un motor de inferencias y una base de reglas y aserciones, para sugerir interfaces, estrategias de testing, bugs típicos y ayudas de optimización. Aún así, para lograr la base de reglas y aserciones va a hacer falta un experto
  • Programación "Automática". Técnica de construir generadores de código (el antepasado del concepto de Software Factories). Brooks no obstante se cuestiona si este tipo de soluciones es generalizable
  • Programación Visual. El autor se muestra escéptico del avance de esta tecnología principalmente debido al estado del arte de los monitores de aquellos años. Hoy creo que no pensaría lo mismo
  • Verificación de Programas. Consiste en detectar bugs ya desde la etapa de diseño o incluso antes aún, en la cadena hacia la construcción. Brooks opina que cuando mucho permitirá reducir la carga de testing de programa, pero sin eliminarla del todo
  • Entornos y herramientas. Enumerando características deseables tales como editores inteligentes para lenguajes específicos que permitan reducir errores sintácticos, así como otras características, Brooks anticipó a Visual Studio (al Intellisense!) por al menos una década

El artículo termina mencionando ataques a la complejidad escencial del software que el autor ya vislumbraba prometedores (y no se equivocó!)

  • Comprar versus construir. Con un ojo biónico, Brooks enuncia los ahorros en los costos del proyecto si se adquieren paquetes de software ad hoc en lugar de lidiar con las fases de construcción y mantenimiento en forma casera
  • Refinamientos en los requerimientos y prototipado rápido. Me pone la piel de gallina leer la justificación del autor de los beneficios de hacer que el proceso sea iterativo e incremental, habida cuenta de que el usuario va a sentir mayor seguridad de lo que quiere tener si previamente va probando prototipos en forma iterativa y los va refinando incrementalmente. Diez y quince años más tarde respectivamente, procesos de desarrollo como el Proceso Unificado (Unified Process o UP), Extreme Programming (XP) mostrarían nuevamente que Brooks donde puso el ojo puso la bala (aunque ésta no fuera de plata)

El artículo es más extenso y le he obviado algunas partes. No obstante es sorprendente la forma precisa en que Brooks predijo lo que iba a ocurrir. En qué forma pudo haber influenciado este gurú?

Esta entrada fue publicada en Software Management. Guarda el enlace permanente.

Una respuesta a El cazador del hombre-lobo (sin bala de plata)

  1. Unknown dijo:

    Totalmente de acuerdo, el tipo es un groso. Y para aquellos que quieran saber más de este genio, les recomiendo leer su clásico libro "The Mythical Man-Month". Enjoy it!

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s