Trabajar con la ley del cambio en mente

Cuanto más tiempo viva tu aplicación, más probable será que tenga que cambiar; así de sencillo y contundente.

En ocasiones me han preguntado por qué parezco obsesionado por programar y diseñar de la manera más simple y legible posibles, para qué preocuparse ahora por aquello que puede o no necesitar cambiar en el futuro. La pregunta en sí ya encierra cierta candidez acerca de los artefactos que generamos en nuestra profesión.

Una de las verdades sobre nuestro trabajo, entronada a modo de ley, nos dice que cuanto más tiempo viva nuestra aplicación, programa, sistema, plugin, framework, etc. más probable será que necesite cambios, mejoras, correcciones, etc. Ley o no, lo que sí puedo decir es que ningún software en el que he participado ha permanecido inmutable más de seis meses...

¿Tenemos presente en nuestro día a día esta realidad?. ¿Nos preocupamos realmente en refactorizar y mejorar a pequeños saltos continuamente?. ¿Nos esforzamos en encontrar la solución más simple a cualquier problema?.

Es cierto que podemos dejar las cosas tal y como nos salen la primera vez que las hacemos (total, funcionan, ¿no?); sin embargo, si vamos dejando cabos sueltos, duplicidades, errores conocidos y toda una estela de debes, con el tiempo se formará una montaña que nos caerá encima inevitablemente (o enterrará el producto en el olvido).

Cualquier software va a necesitar cambios en un futuro necesariamente: cualquier producto que se lance al mercado va a morir si no se renueva con mejoras continuamente (continuous delivery), cualquier cliente consolidado que tengamos nos pedirá mejoras o cambios con toda seguridad, por mucho esfuerzo que hayamos dedicado a probar nuestro código, finalmente el cliente encontrará nuevos errores o pequeños bugs, cuando no nos encontramos con el consabido problema de haber entendido mal algún requisito en concreto. En otras ocasiones, la evolución del mercado o tipología de clientes al que se dirige nuestro software determinará el tipo de cambios a introducir.

Demasiadas razones para no programar centrando nuestro trabajo en la sencillez de las soluciones; esta casi nunca se consigue a la primera, sino que poco a poco, mediante pequeñas refactorizaciones, auscultando el trabajo con tests y a medida que la aplicación crece, vamos mejorándola en todos los aspectos. Tampoco podemos obviar que el coste de evolucionar una aplicación debe ser el mínimo posible, de lo contrario estaremos fuera del mercado antes de lo que nos gustaría.
 

"Aunque suene paradójico, programar profesionalmente significa también estar dispuesto a destruir parte del trabajo realizado ¡precisamente para mejorarlo!. Si nuestro software no puede ser modificado y mejorado fácilmente, estará perdiendo rentabilidad y oportunidades de competir."