En ocasión reciente mientras hacíamos sobremesa o tal vez sería mejor escribir ante mesa, salió una pregunta por ahí de cómo es que eso de “mantener” el software es lo que menos quieren hacer o lo que les aburre más y creo que es una pregunta muy buena que no nos tomamos la molestia en considerar la mayoría de las veces especialmente porque con esta pregunta venia la otra, “¿pero es que el software se está descomponiendo a cada rato?”
Y claro que en su momento una explicación simplista salió, pero a ver si puedo en esta entrada tratar de aclarar o al menos expandir un poco esta interrogante, porque decimos que el mantener el software es lo más pesado y en ocasiones lo más caro.
Bueno en primer lugar hay que decir que en muchos estilos de programación el inventar la rueda es más fácil que mejorar la rueda, por supuesto esto para los ingenieros que no son de software y otras disciplinas que tienen que ver con planear y diseñar suena contra intuitivo y claro que lo es pero en la programación uno puede obtener una cosa que funcione aunque no lo haga de la manera óptima o de plano que “just Works” y sea suficiente al menos para el momento, pero claro mientras se usa se aprende | encuentra | piden cosas que al irse sumando se convierten en verdaderos obstáculos y requieren que el programa sea modificado en tal tamaño o en tantas partes que sea más fácil tirar todo y volverlo a escribir.
Claro no siempre esto es posible o el programa no lo escribimos nosotros y entonces mantener el programa significa el estar arreglando cosas o casos que no se pensaron cuando se escribió el programa original, además normalmente uno no escribe realmente de cero un programa ya sea que utilice o re utilice librerías (digamos segmentos de código que ya realiza tareas comunes) en su programa entonces si de pronto el programa que uno mantiene, no porque sea el programador, ya sea porque sea el empaquetador (caso de Debian) , el administrador de sistemas y aún el usuario final no responde a nuevos casos de uso o a una modificación del caso de uso que ya venía resolviendo eso ya requiere de modificar el programa. Y bueno mencionamos las librerías anteriormente eso es un caso, pero pudiera ser que el programa en si fuese una colección interesante de conexiones entre otros programas que se conectan para poder realizar una o varias tareas, si una de estas librerías queda en desuso, sale una nueva versión o de la que estamos usando aparece una vulnerabilidad de seguridad, va a ser necesario valorar el que hacer para seguir usando este programa o los programas que conforman esta solución.
Siguiendo con las vulnerabilidades de seguridad tiene que ver con las prácticas de programación, no todos siguen las mejores prácticas y no siempre las mejores prácticas incorporan la seguridad en mente, entonces un programa muy eficiente y útil puede contener algún problema de seguridad que nunca había sido descubierto porque nadie lo había usado de cierta forma o como suele suceder, recientemente se descubrió que se puede hacer tal o cual cosa o a alguien se le ocurrió intentar hacer una cosa que no se debería de poder hacer o que se pensó que no es posible realizar y resulta que sí, entonces hay que arreglar el fallo de seguridad esperando que esto no cree otro problema en otra parte del programa o en otros programas que lo utilicen y así hacia adelante.
Por eso hay un dicho que dice “si construyéramos los edificios de la misma forma que escribimos programas, la aparición del primer pájaro carpintero acabaría con la civilización”.
Actualización: 7 mayo 2014, como a la media hora de colocar esta entrada en el FB me encontré con el vinculo a esta otra entrada que con un lenguaje mucho más florido que el mio y con ejemplos bastante jocosos se mete a tratar un tema similar http://stilldrinking.org/programming-sucks, ademas termine de leer, Outliers y para seguir un libro que tengo pendiente de leer completo, me he ido a desempolvar The Mythical Man-Month de Brooks que por supuesto también toca pero de manera mucho más seria el tema.
