¿Por qué es tan difícil conseguir software de calidad?

Es curiosa la doble reputación que tiene hoy en día la informática. Por un lado, ha permitido crear dispositivos «mágicos» de capacidad casi ilimitada, que pueden substituir (o superar) a los humanos y que hasta pueden dejarnos sin trabajo en el futuro. Pero, simultáneamente, se le acusa de construir dispositivos y programas difíciles de usar y que fallan muy a menudo. ¿Por qué hay tantas quejas sobre la calidad del software? ¿Acaso en 2016 aún no hemos aprendido a desarrollar software? ¿Es tan complejo el proceso de desarrollo?

En primer lugar, en relación a la calidad del software hay dos cuestiones complementarias que hay que resolver:

-La primera cuestión es la verificación («is the product right?«): que consiste en asegurar que el software está libre de errores. Esta comprobación puede realizarse mediante pruebas de diferentes clases (pruebas unitarias, pruebas de integración, …) o bien mediante herramientas automáticas que analizan el código para encontrar errores.

-La segunda cuestión es la validación («is it the right product?«): estudiar si el software satisface los requisitos y expectativas de todos los stakeholders. Los requisitos pueden ser de tipo funcional («la aplicación debe hacer X») o de tipo no funcional («la aplicación debe funcionar aunque no  haya conexión a Internet»).

Es decir, no es suficiente comprobar que no hay bugs, también es importante hacer todo lo que se espera. Si la aplicación no hace lo que se quería, o va demasiado lento o no es lo suficientemente seguro tampoco me servirá. Y recoger los requisitos de una aplicación puede ser complejo: tal vez no seamos expertos en el dominio, puede que los usuarios no tengan requisitos bien definidos.

Por otro lado, existen múltiples factores que dificultan conseguir un nivel de calidad adecuado en un proceso de desarrollo de software:

-El tamaño de las aplicaciones ha ido creciendo con el tiempo. Por ejemplo, consideremos el tamaño del kernel de Linux. La versión 1.0 de 1994 tenía 176 kLOC (miles de líneas de código) mientras que la versión 4.1 de 2015 tenía 110 veces más: 19.5MLOC.

-Ahora diréis que cada vez hay más código de terceros disponible y que cada vez se reutiliza más y se desarrolla menos. Eso es cierto en parte, pero depender de un tercero no te exime de obligaciones respecto a la calidad de tu producto. Primero tienes que saber si ese código tiene errores. También tienes que entender cómo funciona para no generar errores por usarlo incorrectamente. Y por último, debes hacer frente a posibles cambios de versiones… o incluso a su desaparición.

-Los equipos de trabajo crecen… y se dispersan por todo el mundo. Tienes mucha suerte si todo el equipo que trabaja en tu proyecto está en el mismo despacho. O edificio. O ciudad. O país. Puede ser que esté en otro continente, con otros horarios, otro idioma y una visión diferente del mundo. Por ejemplo, asegúrate que cuando hablas de distancias usáis las mismas unidades.

-Aunque suena a tópico, «vivimos en un mundo globalizado» y la competencia en el mundo del software es feroz. Adelantarse a tus rivales puede ser clave y hay una gran presión por tener un producto bueno hoy mejor que uno perfecto mañana. De hecho, el lema «done is better than perfect» fue adoptado por Facebook como un mantra.

-Siguiendo la misma línea, la calidad tiene un coste añadido en el proceso de desarrollo… que luego se recupera multiplicado por mil, pero esta inversión inicial es necesaria.  En la actualidad, muchos modelos de negocio se basan en ofrecer software gratuito y recibir ingresos mediante otros canales, como los anuncios, los servicios premium o las compras en las aplicaciones. El hecho que el usuario final asuma que el software «es gratis» puede que el control sobre los costes en el proceso de desarrollo sean más exigentes. Y la calidad suele ser una de las primeras víctimas.

-En un mundo perfecto, los requisitos serían inmutables desde el inicio hasta el final del proyecto. Sin embargo, los proyectos cada vez tienen una vida útil más larga y resulta difícil predecir cómo va usarse una aplicación en el futuro. Cada modifiación en los requisitos implica cambios en el código que pueden introducir errores imprevistos. De vez en cuando hace falta parar las máquinas y hacer limpieza (refactoring) para evitar que el caos sea absoluto.

En resumen, el software tiene una complejidad creciente y mucha presión respecto al coste y los tiempos de entrega, factores que pueden complicar conseguir un nivel de calidad razonable. La ingeniería del software como disciplina introduce procesos, técnicas y herramientas que hacen más manejable los proyectos de desarrollo y mejoran la calidad del software final. Pero. como dice el chiste, «Dios y yo tenemos un acuerdo, él no hace software y yo no hago milagros«.