Una historia de dos valores
Cada aplicación de software que se desarrolla proporciona dos valores: comportamiento y estructura.
Los desarrolladores de software somos responsables de garantizar que ambos valores se mantengan en niveles de calidad altos.
Sin embargo, he visto demasiadas veces como nos enfocamos en uno excluyendo al otro.
Pero puede ser peor.
Enfocarse exclusivamente en el menor de los dos valores, lo que nos llevará a dejar la aplicación en el futuro en momentos temporales o definitivos sin utilidad.
Comportamiento
El primer valor del software es su comportamiento.
A los desarrolladores nos contratan para crear aplicaciones que se comporten de una manera que genere o, automatizando procesos, ahorre dinero al cliente.
Hacemos esto ayudando al cliente a desarrollar una especificación funcional o de requisitos.
Luego, escribimos el código que hace que se satisfagan esos requisitos.
En ocasiones aparecen errores que violan esos requisitos. Entonces los desarrolladores depuramos y solucionamos los problemas.
Otras veces los requisitos van cambiando con el tiempo porque aparecen nuevas necesidades. Esto puede suceder por diferentes motivos como consecuencia de la experiencia del cliente con la aplicación, nuevas necesidades, etc.
Entonces desarrollamos las nuevas características.
El comportamiento es lo más importante para nuestros clientes.
Les encanta cuando añadimos comportamiento, si es lo que querían. Y si modificamos o eliminamos comportamiento importante para su negocio, dejan de confiar en nosotros.
El problema es cuando pensamos que nuestro trabajo termina aquí y nos quedamos con solo una cara de la moneda.
Arquitectura o diseño
El segundo valor de software tiene que ver con la palabra "software", una palabra compuesta por "soft" y "ware".
La palabra "ware" significa "producto". La palabra "suave"... bueno, ahí es donde radica el segundo valor.
El software se inventó para ser "suave".
Estaba destinado a ser una forma de cambiar fácilmente el comportamiento desarrollado. Si hubiéramos querido que el comportamiento desarrollado en aplicaciones fuera difícil de cambiar, lo habríamos llamado hardware.
Para cumplir su propósito, el software debe ser suave, es decir, debe ser fácil de cambiar.
Cuando el cliente cambia de opinión sobre una característica, ese cambio debe ser simple y fácil de realizar.
La dificultad de hacer tal cambio debe ser proporcional solo al alcance del cambio, y no a las consecuencias derivadas de la baja calidad del código ya existente.
Es la razón por la que el coste del cambio habitualmente es desproporcionado con la dimensión de los cambios solicitados.
Es la razón por la que normalmente el primer año de desarrollo es mucho más barato que el segundo, y el segundo año es mucho más barato que el tercero.
Cuando nos quedamos simplemente en el valor del comportamiento, cada nueva solicitud o cambio es más difícil de ajustar que la anterior.
El problema, por supuesto, es el descuido por la arquitectura o diseño del sistema.
¿Qué valor es el más importante?
¿Comportamiento o arquitectura?
¿Es más importante que el sistema de software funcione o es más importante que el sistema de software sea fácil de cambiar?.
Si le preguntas a los clientes te dirán que es más importante que el sistema de software funcione. Hay managers o incluso desarrolladores, a su vez, que suelen estar de acuerdo.
Pero para mí, no es correcto.
Mi razonamiento se basa en examinar los extremos.
• Si me das una aplicación que funciona perfectamente, pero que es imposible de cambiar o que suponga un coste inasumible, no podré hacerlo funcionar cuando cambien los requisitos o aparezcan errores. Por lo tanto, llegará un momento que la aplicación no será útil.
• Si me das una aplicación que no funciona, pero es fácil de cambiar, puedo hacer que funcione y mantenerlo funcionando a medida que cambian los requisitos. En consecuencia, la aplicación seguirá siendo útil siempre en el futuro.
Soy capaz de hacer que la aplicación siga viva en el futuro si es fácil de cambiar.
He tratado varias veces con aplicaciones que son imposibles de cambiar, porque el coste del cambio supera el beneficio del mismo.
Si descuidamos el diseño, las aplicaciones llegan a ese punto en algún momento del futuro.
Luego queremos empezarla de cero, pero la solución estaba mucho antes.
Conclusiones
Escribir código que funciona es relativamente fácil, sin embargo, escribirlo para que otra persona lo entienda, o tú mismo en el futuro, y sea capaz de modificarlo, es mucho más difícil.
Nuestro trabajo es valioso para las personas que usarán el software, pero también para las que se encargarán de su mantenimiento en el futuro, que podemos ser nosotros mismos.