A grandes rasgos, el desarrollo del software sigue unas etapas: se planifica (etapas previas de tomas de requisitos y análisis), se desarrolla (programación e implantación), se mantiene (arreglo de posibles fallos durante el uso del mismo, labores administrativas programadas, ...), evoluciona (se agregan nuevas características si surge la necesidad) y, a veces, muere (se deja de utilizar el producto).
Lo habitual es que la etapa de mantenimiento sea la más larga, pero no debería ser la más costosa económicamente. Sin embargo, existes numerosos sistemas en lo que esto no es así.
¿Han trabajado alguna vez con el típico programa con muchos fallos pero que, sin embargo, se utiliza desde hace mucho tiempo y no hay planes para sustituirlo? ¿Les suena la situación cuando todo el conocimiento de "las tripas" de una aplicación se deposita en muy pocas personas (incluso en una sóla)? ¿Utilizan algún programa que sólo funciona en algunos entornos muy específicos con unas versiones muy concretas del sistema operativo y otras aplicaciones? ¿Se gasta su empresa un dineral en personal subcontratado para que este programa siga malfuncionando?
Todos estos son los síntomas del "software insostenible" (la nomenclatura es propia). Programas y aplicaciones que no han sido bien gestionados y se han escapado de las manos de los que los diseñaron, los programaron, los mantienen y de los que pagan todo esto, el cliente final.
Al final nos encontramos con un dinosaurio software, lento, grande y arcaico. Los usuarios lo odian porque nunca acaba de ir bien, los responsables de área lo odian porque se lleva muchos recursos presupuestarios, los desarrolladores lo odian porque es asqueroso trabajar con el código enmarañado y mil veces parcheado, ...
Lo peor en estos casos es que la solución más obvia, que es rehacer la chapuza, o al menos, dedicarle un buen tiempo para poner orden y concierto, sale muy caro (además, no hay garantía de que la nueva versión sea buena). Pero también sigue siendo muy caro el mantener la aplicación. Un buen dilema económico.
Algunas causas:
- Mala planificación o diseño previo.
Frecuentemente las tomas de requisitos son muy vagas o imprecisas. Esto conlleva hacer cambios importantes cuando el programa ya está en producción, con los riesgos que esto conlleva: prisas, código rápido y sucio, desintegración entre las distintas partes del programa, ... - Uso de una herramientas/lenguajes inadecuados y/o obsoletos.
Algunas herramientas (lenguajes de programación, entornos de desarrollo, etc) son muy permisivas con las malas prácticas al desarrollar software. Dejan una libertad de actuación al desarrollador que puede ser perjudicial al no forzar una buena organización del trabajo y del código. - Mala organización del personal.
Personal novato al que se le pone a trabajar sin una adecuada formación y supervisión en clientes finales, alta rotación del personal, jefes de proyecto/analistas sin vocación técnica que no revisan el código que se produce, ... - Clientes mal acostumbrados.
Muchos clientes quieren las cosas para ya, y no siempre es posible hacer algo rápido y bien. Si una mejora requiere un estudio y análisis, así se le debe comunicar al cliente, y no ponerse a picar código como locos.
Podría seguir enumerando más errores, pero no merece la pena. ¿Existe alguna solución para este desaguisado?
Probablemente para los sistemas existentes sea difícil encontrarla, pero hay que aprender de los fallos:
- Sres. contratantes: no fuerce a los profesionales que contrate. Si le dan unas estimaciones, respételas, no son gratuitas.
Desconfíe de empresas de desarrollo o consultoras con mucha rotación de personal. Infórmese antes de cómo se trabaja en ellas. Los "obreros del software" somos también muy importantes, no sólo los encorbatados que van a presentar y vender el producto. - Sres. contratados: no sucumban a la tentación de dar plazos cortos, ni de presentar presupuestos muy bajos. Sean realistas.
Cuiden y formen bien a sus "picateclas", pero supervisen su trabajo: no para sancionar, sino para mejorar. Hagan una buena ingeniería y planificación, no se "aten" en exceso a una tecnología.
Leo en