Cada cierto tiempo me gusta volver, una y otra vez, a leer este interesante articulo, que describe la decadencia en la que estan o podrian estar algunos proyectos de software. Tampoco voy a mentir u ocultar que algun proyecto que paso por mis manos (y cayo en otras) ha llegado a “podrirse” irremediablemente. Pero si analizamos el articulo a un nivel mas general, a lo que se refiere es a la capacidad y cualidad de mantenibilidad (no se si esta palabra exista siquiera) que tiene un artefacto de software. En otras palabras una pieza de software tendera a podrirse mas rapidamente mientras menor sea su capacidad de ser mantenible
 |
Entonces. el debate que debemos enfocar en cualquier caso (creo yo), NO ES si el software debe podrirse o no, sino cuan RAPIDO debe podrirse. Porque indudablemente en algun momento ese software que tanto nos costo disenar e implementar, terminara por derrumbarse (y aqui debo hacer uso de la |
 |
Nuestro software puede y debe ser resitente a factores de cambio “obvios”, es decir a aquellos factores que podemos controlar, como los que son descritos en el articulo referenciado, tales como la viscosidad, rigidez, fragilidad e inmovilidad. Por otra parte, los factores que no podemos controlar, son aquellos que produciran el deterioro “natural” de un proyecto de software. Entre los factores que esta fuera de nuestro control, puedo enumerar: Los cambios en el liderazgo, cambios de vision del proyecto, cambios tecnologicos, cambios en los recursos humanos, etc. Yo puedo aceptar que un producto de software, se deteriore “o se vaya pudriendo” por aquellos cambios sobre los que yo no tengo control, pero no aceptare nunca que el mismo producto se derrumbe por aquellos factores en los que si pude hacer algo para evitar su caida. |
Desde mi humilde punto de vista y como aporte a los articulos referenciados puedo decir que, muchos problemas de mantenibilidad de un producto de software se deben a la gran diferencia, entre Resolver un Problema y Solucionar un Problema.
 |
Aunque a primera vista ambas frases podrian parecer lo mismo, el concepto detras de “Resolver un problema” va ligado a un parche temporal que se aplica para corregir un problema reportado, en cambio el concepto de “Solucionar un problema” esta vinculado a un proceso mas prolongado de razonamiento e implementacion, para corregir el mismo problema. Mientras el que resuelve el problema ve solo el arbol y se avoca a eliminar de la lista de sus tareas ese incomodo elemento llamado bug, lo mas rapido posible y aplicando una correccion inmediatista, que tarde o temprano provocara o iniciara otro punto de deterioro. En su lugar el que soluciona el problema ve el bosque, toma su tiempo para analizar la implicancia de su correccion y elige la alternativa que brinde un balance entre la urgencia por solucionar el problema y la batalla interna por sostener una buena estructura futura que impida el inicio de un punto de deterioro. |
Es por esto que en los equipos de desarrollo que he tenido el gusto de dirigir, mi sugerencia implicita o explicita en otros casos fue: En desarrollo de software, cuando encuentras un problema, por favor NO resuelvas el problema, SOLUCIONA el problema!
La podredumbre del software, se puede retrasar aplicando soluciones a los problemas que vayan apareciendo y aunque estoy consciente que en algunos escenarios no es posible tomarse mucho tiempo para razonar una solucion, siempre es posible volver hacia atras y remover ese horrendo parche que introdujimos al resolver un problema. 
Saludos.