Debemos separar entre las distintas etapas que hacen a la vida de una aplicación , se separan en desarrollo, prueba, producción y mantenimiento.

Cuando el software está en etapa de desarrollo o de prueba, es infinitamente maleable; puede ser formado completamente al gusto de sus implementadores. Pero tan pronto como un proyecto dado crece más y más (etapa de producción), y desarrolla una gran base de usuarios con mayor experiencia con el software, se vuelve menos y menos maleable. Como un metal que ha sido forjado, el software se vuelve un sistema heredado, frágil e incapaz de ser fácilmente cambiado sin fracturar el sistema completo.

• Los usuarios esperan una relativamente constante interfaz de usuario; una vez que una característica ha sido implementada y expuesta a los usuarios, es muy difícil de convencerlos de aceptar cambios mayores a esa característica, incluso si esa característica no estaba bien diseñada en principio o la existencia de la misma bloquea un mayor progreso.

• Demasiada documentación puede describir el comportamiento actual (del software) y sería costoso de cambiar. Además, es esencialmente imposible recordar todas las copias de la documentación existente así que es más probable que los usuarios se refieran de nuevo a los manuales obsoletos de todos modos.

• Los implementadores originales (aquellos que conocían cómo las cosas realmente funcionaban o como se implementaron) pueden no recordar, o haber ido a otra empresa o lugar. Los mismos pueden haber dejado una documentación insuficiente del funcionamiento interno del software. Muchos detalles de implementaciones de tamaño pequeño solamente fueron entendidos a través de las transmisión oral directa del equipo de diseño y muchos de estos detalles se han perdido, o se han podido perder, aunque algunos pueden ser redescubiertos a través de la aplicación diligente de una arqueología de software. Sobre esto Cunningham, Hunt, Marick y Thomas explican :

A los programadores a menudo se les entrega un sistema (de software) de tamaño considerable, construido por gente que no conocen, tocado por muchas personas desde entonces, documentado mínimamente si es que lo fue. Se les dice que lo mejoren. Su tarea debería ser corregir un error, agregar una característica, o una refabricación completa. Están bajo la presión del tiempo, así que necesitan minimizar el tiempo total destinado a aprender del sistema y el tiempo gastado en mejorarlo. Cunningham, Hunt, Marick & Thomas

• Los parches software se han efectuado probablemente a través de los años, cambiando sutilmente el comportamiento del software. En muchos casos, estos parches corrigen el fallo por el cual fueron efectuados pero introducen otros fallos más sutiles en el sistema. Estos fallos sutiles hacen cambios subsecuentes al sistema lo que lo vuelve finalmente más complicado.

Está demostrado que la mayor incidencia en los costos de una aplicación está en su mantenimiento.

Es común para los sistemas de software volverse ligeramente frágiles dentro de, digamos, cinco años y casi inmantenibles dentro de quince años. Es muy raro que encontremos un proyecto de software tan bien diseñado que pueda sostenerse un período mayor siendo fácilmente mantenible. Más a menudo, la antigua base de código será simplemente abandonada y un sistema completamente nuevo será iniciado desde cero; el nuevo sistema puede estar libre de muchas de las cargas del sistema heredado.

• Edward Yourdon
• Fred Brooks
• The Mythical Man-Month

• Crisis del software
• Hediondez del código
• Entropía del software
• Pudrición del software
• Principio de Peter del software