Mitos de la programación: El nuevo sistema que lo solucionara todo.

Toda pieza de software esta destinada a ser descartada en algún momento de su vida útil. Los sistemas son sustituidos por otros nuevos y mejores, al menos en la teoría. La sustitución de un programa representa en algunas empresas la oportunidad de empezar de nuevo, no hay que lidiar con legados, ni con errores heredados. Puedes construir a tus anchas sin miedo; casi todos los programadores, si pueden elegir entre un proyecto de tipo “green field”  o un “brown field” elegirán el primero. Hay que ser cuidadosos a la hora de plantear un sistema nuevo que reemplazara al obsoleto, esto tiene implicaciones que debes de considerar. A continuación te las menciono.

Escribir nuevas lineas de código es fácil. Demasiado fácil.

Cualquiera puede tirar de lineas que resuelva un problema, es el requisito mínimo para ser considerado programador. Es tentador ser el programador que puede ofrecer la solución que saque a la empresa del lodo de los  legados, construyendo un nuevo sistema que no tendrá los errores del anterior. En raras ocasiones se contempla el construir a partir de lo existente, o ver los motivos por los cuales el sistema anterior fallo. Por lo general se apunta al programador anterior, aquel fue el malo. El equipo anterior cometió errores imperdonables y obvios, que el nuevo no hará y por lo tanto entregara una mejor solución. Pero, ¿de verdad se sabe como funciona el sistema?

Todo sistema representa conocimiento adquirido.

Aunque no se vea, todos los sistemas guardan conocimiento acerca de como funciona, o debe de funcionar la empresa. No siempre este conocimiento es obvio y fácil de leer. Un código de mala calidad suele ocultar que es una regla de negocio, un bug, o parte del diseño de la aplicación. Si la meta de un programador es replicar un sistema a partir de otro sistema  que no es claro en su funcionamiento, es seguro que habrá fallas y bugs. Los problemas empezaran a surgir en el momento que los flujos no puedan ser completados o el camino ideal del programa tenga variantes inesperadas. Es común oír de tus clientes internos el: “es que el sistema anterior hacia esto” o “¿porque no esta X función?, si antes si estaba”. Si, no puedes saber todos los caminos posibles del sistema, desgraciadamente los faltantes o malentendidos van a comenzar a generar desconfianza en el sistema nuevo que no iba a tener errores.

Dale la importancia que se merece al sistema actual.

Un sistema que funciona mal o deficientemente pero funciona, es indistinguible de un sistema que funciona bien para el usuario final. Tus usuarios y tus clientes internos pueden esperar la misma funcionalidad que ofrecía el anterior. Puede que mejores un proceso o un flujo de trabajo y el cambio sea impopular, porque ya todos estaban acostumbrados al flujo anterior. Presta atención a los flujos de trabajo y el uso que le están dando tus usuarios. Registra los problemas y desperdicios que se presenta el aplicativo actual (siempre desde la perspectiva del usuario, no la tuya), de ser posible no cambies la interfaz gráfica a menos que sea estrictamente necesario. Los usuarios acostumbrados a un flujo de trabajo  suelen presentar resistencia e incluso oposición a los cambios. La perdida de conocimiento o la ignorancia se considera un desperdicio en los proyectos de mejora.

No tienes que tirar todo el sistema anterior.

Siempre hay riesgo en reemplazar aplicaciones que no conoces al 100%, la perdida de funcionalidad o conocimiento es un problema común. Puedes construir funcionalidades nuevas o agregar mejoras a los sistemas actuales desde adentro, sin tener que añadir construcciones nuevas a las arquitecturas de la empresa. La opción de desmantelar el sistema desde dentro tiene la ventaja de que puedes ofrecer exactamente el comportamiento esperado sin el coste de quemarte por fallas  que prometiste no cometer. Las expectativas de tus clientes  internos y tus usuarios son menores. Vas a comenzar convirtiendo la aplicación monolítica en módulos que pueden estar desacoplados lógica o físicamente. Cualquier modulo que no puedas refactorizar puede quedarse funcionando sin que lo toques.

El habito de reparar y mejorar siempre es mejor que volver a construir.

Siempre es mejor opción pagar la deuda técnica que has heredado, antes que volver a contraer mas deuda. En el fondo un sistema nuevo construido a partir de otro es deuda técnica en otro sabor.

La acción de guerrilla de reparar, luego refactorizar y desacoplar,después agregar pruebas automatizadas y  por ultimo recibir feedback reporta mayores beneficios a la larga. Los sistemas se vuelven complejos e inestables por  un bajo compromiso del equipo para mantener la calidad. Tener dos sistemas el nuevo y el viejo con altas cantidades de deuda técnica que pagar, solo ocasiona problemas. Si las aplicaciones anteriores tuvieron  bajo compromiso de sus programadores, las nuevas tendrán ese mismo destino.

Conclusiones.

El principal enemigo del programador es la complejidad. Es muy fácil que un sistema se haga complejo en muy poco tiempo, en cambio, es muy difícil hacer que una pieza de software reduzca su nivel de complejidad. El habito de corregir y reparar en el menor tiempo posible los problemas del día a día, te previenen de llegar a la situación de tener que construir algo de nuevo.

Si no tiras la basura de tu casa periódicamente, pronto esta se llenara. Tienes dos opciones: vas y compras una casa nueva o… periódicamente esperas el camión y se la entregas.

Autor imagen: Albert Koch 

Gustavo Sánchez