Leyes de Lehman. Introducción II
Otro aporte de Lehman consistió en el hecho de que conforme se evoluciona un producto crece su complejidad y su tamaño, lo que hace que cada vez sean más costosas esas actividades.
Por tanto, el mantenimiento de un producto es inevitable y su coste (como consecuencia de una mayor complejidad) irá creciendo a lo largo del tiempo. De ahí que se considere que el software no se desgasta, pero sí que se deteriora.
Recordemos una conocida cita de Fred Brooks: «La complejidad del software es una propiedad esencial, no accidental».
¿Es posible poner medios? Claro que sí, tanto en las actividades ordinarias de desarrollo (aplicando buenas prácticas y considerando la refactorización como parte del propio proceso de desarrollo) como con actividades extraordinarias (planes de acción para simplificar la arquitectura del sistema, reducir la deuda técnica, etc…). No obstante, debemos tener en cuenta que con independencia de estas actividades sí que es cierto que la complejidad del sistema crece conforme el mismo evoluciona.
Más controvertidas resultan otras afirmaciones de Lehman, en las cuales considera que determinados atributos relacionados con el desarrollo de software (tamaño, número de defectos, tasa de crecimiento), etc…, se mantienen más o menos constantes o siguen una tendencia (una proporcionalidad) a lo largo del proceso de evolución del software.
Estas afirmaciones, personalmente me parecen más discutibles (no quiero decir que no esté de acuerdo en todas), si bien, pese a que me base en mi propia experiencia, no he analizado datos empíricos para verificar si efectivamente se cumplen o no.
Jummp 