plata

No hay balas de plata. Esencia y accidentes de la ingenier´ıa de software
Anthony Hall*
University of North Chapel Hill

Manejar constructos complejos es la esencia; tareas accidentales aparecen al representar estos constructos en alg´
un lenguaje. El progreso en el pasado ha reducido las tareas accidentales de manera tal
que el progreso ahora depende de resolver la esencia.
De todos losmonstruos que llenan las pesadillas de nuestro folklore, ninguno aterroriza m´as que los hombreslobo, porque se transforman de manera inesperada de algo familial a algo horroroso. Para ellos se buscan balas
de plata que puedan destruirlos de forma m´agica.
Los proyectos de software habituales, al menos tal como los ve un administrador no t´ecnico, tiene algunas de
estas caracter´ısticas; generalmente seve inocente y directo, pero puede transformarse en un monstruo de plazos
no alcanzados, presupuestos sobrepasados, y productos con errores. Entonces se escuchan gritos desesperados
pidiendo una bala de plata–algo que haga disminuir los costos del software tan r´apidamente como bajan los
costos del hardware.
Pero, si miramos con un horizonte de diez a˜
nos, no vemos ninguna bala de plata. No existeni un solo desarrollo,,
ni en tecnolog´ıa ni en administraci´
on, que por s´ı mismo prometa ni siquiera un orden de magnitud de mejoras en
la productividad, confiabilidad, o simplicidad. En este art´ıculo, tratar´e de mostrar por qu´e, examinando tanto
la naturaleza de los problemas del software como las propiedades de las balas que han sido propuestas.
Sin embargo, escepticismo no es lo mismo quepesimismo. A pesar de que no vislumbramos grandes saltos
cualitativos–y por cierto creo que esto es consistente con la naturaleza del software–existen en desarrollo muchas
innovaciones promisorias. Un esfuerzo disciplinado y consistente para desarrollar, propagar y explotar estas
innovaciones deber´ıa por cierto traer un orden de magnitud de mejora. No existe un camino real, pero este es elcamino.
El primer paso hacia la cura de las enfermedades fue reemplazar las teor´ıas de los demonios por la teor´ıa de los
g´ermenes. S´olo ese cambio en s´ı, el comienzo de la esperanza, quita toda esperanza de soluciones m´agicas. Esto
ense˜
n´o a los trabajadores que el progreso se har´ıa paso a paso, con gran esfuerzo, y que se deber´ıa tener una
disciplina persistente con la limpieza. De la mismaforma se encuentra hoy la ingenier´ıa de software.

Es necesario que sea dif´ıcil? – Dificultades esenciales
No s´olo no existe ninguna bala de plata a la vista, sino que la naturaleza del software en s´ı hace improbable
que exista ninguna–ning´
un invento har´
a a la productividad, confiabilidad, y simplicidad lo que la electr´onica, los
transistores, y la integraci´
on a gran escala hicieron porel hardware de los computadores. No podremos entonces
esperar mejorar las ganancias al doble cada dos a˜
nos.
* Originalmente publicado en Information Processing 1986, ISBN No. 0444-7077-3, H. J. Kugler, Ed., Elsevia Science Publishers
B.V. (North-holland) IFIP 1986. Traducido por Mar´ıa Cecilia Bastarrica en agosto de 2006.

1

Primeramente, debemos observar que la anomal´ıa no es que elprogreso del software es muy lento, sino que
el progreso en hardware es muy r´
apido. Ninguna otra tecnolog´ıa desde el inicio de la civilizaci´on ha tenido seis
´ordenes de magnitud de aumentos en sus ganancias en la relaci´on precio-performance en 30 a˜
nos. En ninguna otra
tecnolog´ıa se puede escoger tomar las ganancias o bien en mejoras en la performance o en reducir los costos. Estas
gananciasprovienen de la transformaci´
on de la industria de los computadores de una industria de ensamblaja a
una industria de procesos.
En segundo t´ermino, para apreciar la tasa de progreso que se puede esperar en tecnolog´ıas de software, examinemos sus dificultades. De acuerdo con Arist´oteles, las dividimos en esencia, o dificultades inherentes a la
naturaleza del software, y accidentes, o sea esas...