Leyes de Lehman. Introducción I
En los próximos días se van a publicar una serie de artículos sobre las 8 leyes de Lehman de evolución de los sistemas.
Lo más significativo de ellas es que trata de establecer una serie de pautas relacionadas con la evolución de los sistemas, tratando de generalizar ese comportamiento al conjunto de los mismos.
No es necesario estar de acuerdo con las mismas, de hecho, hay alguna que os parecerá más que discutible o que aplicando el enfoque adecuado se puede resolver o atenuar el problema que describe.
Me parece especialmente interesante el hecho de que Lehman considere la evolución de los sistemas (su mantenimiento) como algo inevitable, por mucho que te esfuerces en desarrollar una versión del producto que trate de ser definitiva.
Uno de los problemas que nos encontramos los desarrolladores de software es que el área usuaria no entiende que un producto requiera de un mantenimiento posterior, pese a que sean ellos mismos los que sugieran o provoquen esos cambios (pese a que entiendan que deberían haber sido tenidos en cuenta en el proceso de desarrollo). Y eso que tienen todos los ejemplos que quieran en el mundo real, más allá del desarrollo de software, para entender la necesidad de una evolución, una adaptación o un mantenimiento del software.
Es cierto que el software es un elemento lógico y que como tal no se desgasta (de ahí la diferencia con el mantenimiento de un elemento físico) pero también lo es que las necesidades de los usuarios, de la organización o del negocio varían, así como su capacidad de inversión (lo mismo hay funcionalidades que no se abordaron por su coste que ahora sí que interesa llevar a cabo) y no se puede pretender, por irreal, que una primera versión finalista del software tenga en cuenta no solo las necesidades presentes sino las futuras (algo que por otra parte sería temerario salvo que se tuviera muy claro cuál es la línea de evolución del producto, algo que en muchos casos depende de muchos factores y variables externas).
La evolución del sistema no solo va a ser motivada por cambios originados por los usuarios y/o por el contexto (puede ser necesario modificar la aplicación para poder dar una respuesta a un determinado movimiento de un competidor en el mercado o para adelantarse a él), sino por la propia infraestructura que lo sustenta o incluso por los propios componentes, librerías, artefactos o backends que utiliza.
Esos elementos que pueden ser físicos o lógicos también evolucionan y la organización responde a esos cambios actualizando las diferentes versiones que utilizan de los mismos o sustituyéndolos por otros, ya que generalmente resuelven problemas de seguridad, robustez, rendimiento y eficiencia. Además estos cambios de versiones llevan aparejados una pérdida de soporte por parte del fabricante, por lo que por un motivo o por otro no tenemos más remedio que terminar evolucionándolos.
Este cambio, a su vez provoca una evolución de los propios sistemas (tareas en este caso de mantenimiento adaptativo), con el objeto de que puedan seguir funcionando en ese nuevo contexto tecnológico.
Lo mismo sucedería, por ejemplo, con las propias librerías que utiliza la aplicación, ¿no cambiaríamos de versión de determinadas librerías (siempre y cuando tengamos la oportunidad de hacerlo) si las nuevas versiones mejoran, por ejemplo, el rendimiento del sistema?.
Jummp 