El desarrollo de software, en tanto que disciplina, se fundamenta en parámetros, variables, bibliotecas y muchos más elementos. En la combinación de todos ellos, no puede haber fallos pero, a veces, suceden y proyectos que parecían destinados al éxito y que se diseñaron para hacer más fáciles procesos y tareas fracasan por falta de presupuesto, programadores perfeccionistas en exceso e, incluso, injerencias administrativas. Hay, sin embargo, una serie de errores recurrentes que, de tan repetidos, merecen la pena reseñarse, ya que uno, varios o, incluso, todos a la vez suelen darse, de una manera u otra, en los proyectos fallidos.
Elegir la metodología equivocada
Todas las metodologías de desarrollo de software tienen seguidores apasionados por las reglas que definen su forma favorita de organizar un equipo. El problema suele estar en elegir el adecuado para su equipo. Imponer reglas desde arriba es mala idea, porque no hay nada peor que poner a un programador a trabajar desde un enfoque que no consideran adecuado. Con todo, permitir a los programadores que escojan la metodología que satisface sus intereses y deseos siempre es también un error. Por tanto, es clave el consenso, porque con una metodología adecuada se reducirán las fricciones y todo el mundo sabrá qué debe hacer y qué se espera de él.
Escalabilidad
Crear un código eficaz sin cuellos de botella que sorprenda a todos cuando la aplicación finalmente se ejecute a gran escala requiere mucha previsión y liderazgo. No es algo que pueda solucionarse más adelante con un poco de codificación específica y cinta adhesiva virtual. Así, algoritmos y estructuras de datos se deben planificar desde inicio porque, más pronto o más tarde y si la aplicación funciona, aparecerá, primero, un millón de usuarios y, después, mil millones.
No hay que ser víctima de las tendencias
Los desarrolladores de software suelen sentirse siempre atraídos por las ideas más nuevas y llamativas y, aunque estas ideas pueden llegar a solucionar problemas, también pueden acabar frenando proyectos enteros, ya que utilizar una nueva herramienta sólo es posible tras un mínimo periodo de aprendizaje. Las nuevas ideas, precisamente por su carácter novedoso, pueden llevar en su seno defectos ocultos. Así, si tenemos plazos de entrega concretos, mejor no inventar y usar lo que sabemos que funciona y todo el mundo sabe emplear a la perfección. ¿Por qué hay empresas que todavía ejecutan software escrito en COBOL? Justo por eso.
Almacenar datos que nunca se utilizarán y evitar las pruebas
Por su formación, los programadores tienden a almacenar información para hacer frente a fallos de seguridad o violaciones de privacidad que nunca se acaban dando. Hay que ser, además especialmente cuidadoso con los datos sensibles, porque si los almacenamos sin permiso, podemos tener problemas. Y nunca hay que olvidar que una buena arquitectura de software implica planificar para que la cantidad de datos que se almacena sea mínima y se reduzcan costes al tiempo que la velocidad del sistema es mayor. Tampoco es buena idea ahorrarse pruebas que, aunque son un desafío constante, resultan fundamentales para testar el código y conseguir que siga siendo viable durante todo el proceso de desarrollo.
Subcontratar el trabajo equivocado
El debate sobre la creación o compra de software es un debate tradicional que no tiene una conclusión definitiva. Aun así, los desarrolladores de software suelen elegir mal. Tal vez haya una solución perfectamente buena a buen precio y sean demasiado orgullosos para dejar de lado su pila personalizada con su costoso equipo interno. También ocurre lo contrario. Desafortunadamente, decidir qué herramientas externas utilizar tampoco es sencillo.