Balas de plata

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 ninguna bala de plata. Noexiste 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. Sin embargo, escepticismo noes 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. No existe un camino real, pero estees 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´ tener una no ıa ıa disciplina persistente con lalimpieza. 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 la electr´nica, los u a o transistores, y la integraci´na 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 en agosto de 2006. ıa

1

Primeramente, debemos observarque 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 puede escoger tomar las ganancias o bien en mejoras en la performance o enreducir 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 Arist´teles, las dividimos en esencia, o dificultades inherentes a la o naturaleza...