no hay balas...

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

Manejar constructos complejos es la esencia; tareas accidentales aparecen al representar estos constructos en alg´n lenguaje. El progreso en el pasado ha reducido las tareas accidentales de manera tal
u
que el progreso ahora depende de resolver la esencia.
De todos losmonstruos que llenan las pesadillas de nuestro folklore, ninguno aterroriza m´s que los hombresa
lobo, 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´gica.
a
Los proyectos de software habituales, al menos tal como los ve un administrador no t´cnico, tiene algunas de
e
estas caracter´ısticas; generalmente se ve 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´pidamente como bajan los
a
costos del hardware.
Pero, si miramos con un horizonte de diez a˜os, no vemos ningunabala de plata. No existe ni un solo desarrollo,,
n
ni en tecnolog´ ni en administraci´n, que por s´ mismo prometa ni siquiera un orden de magnitud de mejoras en
ıa
o
ı
la productividad, confiabilidad, o simplicidad. En este art´
ıculo, tratar´ de mostrar por qu´, examinando tanto
e
e
la naturaleza de los problemas del software como las propiedades de las balas que han sido propuestas.
Sinembargo, escepticismo no es lo mismo que pesimismo. 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´ por cierto traer un orden de magnitud de mejora. Noexiste un camino real, pero este es el
ıa
camino.
El primer paso hacia la cura de las enfermedades fue reemplazar las teor´ de los demonios por la teor´ de los
ıas
ıa
g´rmenes. S´lo ese cambio en s´ el comienzo de la esperanza, quita toda esperanza de soluciones m´gicas. Esto
e
o
ı,
a
ense˜´ a los trabajadores que el progreso se har´ paso a paso, con gran esfuerzo, y que se deber´ teneruna
no
ıa
ıa
disciplina persistente con la limpieza. De la misma forma se encuentra hoy la ingenier´ de software.
ıa

Es necesario que sea dif´
ıcil? – Dificultades esenciales
No s´lo no existe ninguna bala de plata a la vista, sino que la naturaleza del software en s´ hace improbable
o
ı
que exista ninguna–ning´n invento har´ a la productividad, confiabilidad, y simplicidad lo que laelectr´nica, los
u
a
o
transistores, y la integraci´n a gran escala hicieron por el hardware de los computadores. No podremos entonces
o
esperar mejorar las ganancias al doble cada dos a˜os.
n
* 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´ Cecilia Bastarrica enagosto de 2006.
ıa

1

Primeramente, debemos observar que la anomal´ no es que el progreso del software es muy lento, sino que
ıa
el progreso en hardware es muy r´pido. Ninguna otra tecnolog´ desde el inicio de la civilizaci´n ha tenido seis
a
ıa
o
o
´rdenes de magnitud de aumentos en sus ganancias en la relaci´n precio-performance en 30 a˜os. En ninguna otra
o
n
tecnolog´ se puedeescoger tomar las ganancias o bien en mejoras en la performance o en reducir los costos. Estas
ıa
ganancias provienen de la transformaci´n de la industria de los computadores de una industria de ensamblaja a
o
una industria de procesos.
En segundo t´rmino, para apreciar la tasa de progreso que se puede esperar en tecnolog´ de software, exe
ıas
aminemos sus dificultades. De acuerdo con...