No hay bala de plata: Esencia y accidentes de la ingeniería de software

No hay bala de plata: Esencia y accidentes de la ingeniería de software
por Frederick P. Brooks, Jr.

De todos los monstruos que llenan las pesadillas de nuestro folclore, ninguno aterroriza más que los hombres lobo, porque se transforman inesperadamente de lo familiar en horrores. Para ellos, se buscan balas de plata que mágicamente puedan darles fin.

El proyecto de software familiar, al menos visto por el gerente no técnico, tiene algo de este carácter; usualmente es inocente y directo, pero es capaz de convertirse en un monstruo de plazos incumplidos, presupuestos desbordados y productos defectuosos. Así, escuchamos gritos desesperados en busca de una bala de plata, algo que haga que los costos del software disminuyan tan rápidamente como lo hacen los costos del hardware.

Pero, al mirar hacia el horizonte de la próxima década, no vemos ninguna bala de plata. No hay un solo desarrollo, ni en tecnología ni en técnicas de gestión, que por sí mismo prometa siquiera una mejora de un orden de magnitud en productividad, fiabilidad o simplicidad. En este artículo, intentaré mostrar por qué, examinando tanto la naturaleza del problema del software como las propiedades de las balas propuestas.

El escepticismo no es pesimismo, sin embargo. Aunque no vemos avances sorprendentes, y de hecho creo que tales avances son inconsistentes con la naturaleza del software, muchas innovaciones alentadoras están en marcha. Un esfuerzo disciplinado y constante para desarrollar, propagar y explotar estas innovaciones debería, en efecto, producir una mejora de un orden de magnitud. No hay un camino real, pero sí hay un camino.

El primer paso hacia el manejo de las enfermedades fue reemplazar las teorías de demonios y humores por la teoría de los gérmenes. Ese mismo paso, el comienzo de la esperanza, en sí mismo destruyó todas las esperanzas de soluciones mágicas. Les dijo a los trabajadores que el progreso se haría de manera gradual, con gran esfuerzo, y que se tendría que prestar una atención constante y persistente a una disciplina de limpieza. Así es hoy con la ingeniería de software.

¿Tiene que ser difícil? — Dificultades esenciales

No solo no hay balas de plata a la vista, sino que la misma naturaleza del software hace improbable que existan. No habrá invenciones que logren para la productividad, fiabilidad y simplicidad del software lo que los electrónicos, transistores y la integración a gran escala hicieron por el hardware de computadoras. No podemos esperar ver nunca un doble incremento cada dos años.

Primero, hay que observar que la anomalía no es que el progreso del software sea tan lento, sino que el progreso del hardware es tan rápido. Ninguna otra tecnología, desde el inicio de la civilización, ha visto seis órdenes de magnitud de mejora en la relación rendimiento-precio en 30 años. En ninguna otra tecnología se puede optar por obtener esa ganancia ya sea en mejor rendimiento o en costos reducidos. Estas mejoras se derivan de la transformación de la manufactura de computadoras, que pasó de ser una industria de ensamblaje a una industria de procesos.

En segundo lugar, para ver qué tasa de progreso se puede esperar en la tecnología de software, examinemos las dificultades de esa tecnología. Siguiendo a Aristóteles, las divido en esencia, las dificultades inherentes a la naturaleza del software, y accidentes, aquellas dificultades que hoy acompañan su producción, pero que no son inherentes.

La esencia de una entidad de software es un constructo de conceptos interconectados: conjuntos de datos, relaciones entre los elementos de datos, algoritmos e invocaciones de funciones. Esta esencia es abstracta, ya que dicho constructo conceptual es el mismo bajo muchas representaciones diferentes. No obstante, es altamente preciso y detallado.

Creo que la parte difícil de construir software es la especificación, el diseño y la prueba de este constructo conceptual, no el trabajo de representarlo y probar la fidelidad de la representación. Todavía cometemos errores de sintaxis, por supuesto, pero son insignificantes en comparación con los errores conceptuales en la mayoría de los sistemas.

Si esto es cierto, construir software siempre será difícil. Inherentemente no hay bala de plata.

Consideremos las propiedades inherentes de esta esencia irreductible de los sistemas de software modernos: complejidad, conformidad, capacidad de cambio e invisibilidad.

Complejidad. Las entidades de software son más complejas para su tamaño que quizás cualquier otro constructo humano, porque no hay dos partes iguales (al menos por encima del nivel de declaración). Si lo son, convertimos las dos partes similares en una subrutina, abierta o cerrada. En este sentido, los sistemas de software difieren profundamente de las computadoras, edificios o automóviles, donde abundan los elementos repetidos.

Las computadoras digitales son, en sí mismas, más complejas que la mayoría de las cosas que las personas construyen: tienen un número muy grande de estados. Esto hace que concebirlas, describirlas y probarlas sea difícil. Los sistemas de software tienen órdenes de magnitud más estados que las computadoras.

De igual manera, escalar una entidad de software no es simplemente una repetición de los mismos elementos en tamaños más grandes; necesariamente implica un aumento en el número de elementos diferentes. En la mayoría de los casos, los elementos interactúan entre sí de manera no lineal, y la complejidad del conjunto aumenta mucho más que de manera lineal.

La complejidad del software es una propiedad esencial, no accidental. Por lo tanto, las descripciones de una entidad de software que abstraen su complejidad a menudo abstraen también su esencia. Durante tres siglos, las matemáticas y las ciencias físicas avanzaron considerablemente al construir modelos simplificados de fenómenos complejos, derivar propiedades de los modelos y verificar esas propiedades mediante experimentos. Este paradigma funcionó porque las complejidades ignoradas en los modelos no eran las propiedades esenciales de los fenómenos. No funciona cuando las complejidades son la esencia.

Muchos de los problemas clásicos del desarrollo de productos de software derivan de esta complejidad esencial y su aumento no lineal con el tamaño. De la complejidad proviene la dificultad de comunicación entre los miembros del equipo, lo que conduce a fallos en el producto, sobrecostos y retrasos en el calendario. De la complejidad proviene la dificultad de enumerar, y mucho menos entender, todos los estados posibles del programa, lo que deriva en su falta de fiabilidad. De la complejidad de la función proviene la dificultad de invocar funciones, lo que hace que los programas sean difíciles de usar. De la complejidad de la estructura proviene la dificultad de extender los programas a nuevas funciones sin crear efectos secundarios. De la complejidad de la estructura provienen los estados no visualizados que constituyen puertas traseras de seguridad.

...