Depende de los requerimientos, depende de los plazos, depende de los clientes, depende de las herramientas. Todo depende. Si nada puede ser preciso, entonces ¿qué es la informática? ¿Qué es el desarrollo de software? ¿Acaso un área imprecisa que solo trata de buscar entender lo que quiere otra persona? ¿O es todo esto una excusa para abandonar los métodos formales?
La informática nace de múltiples áreas del conocimiento, entre ellas la lógica y matemática, pero que, con el paso del tiempo, estás han ido perdiendo repercusión, sobre todo, en la industria. La industria de software está sumergida en la idea ingenieril: siempre habrá errores, por tanto, debemos crear metodologías y técnicas para asumir lo inevitable. El mantra es el siguiente: el software conlleva errores y no es posible de deshacernos de ellos por completo.
Usted quizá ha visto como empresas de cientos de desarrolladores —de gran nivel técnico (se supone)—, cientos de millones de dólares en recursos como Apple, Microsoft, Amazon, etcétera deben ir sacando nuevos parches para corregir bugs de versiones anteriores de sus productos; si ellos que, se asume, están capacitados también sufren de estos inconvenientes, ¿qué nos queda al resto?
Esta idea que, con verdad en los hechos, se ha sustentado en el siglo XXI, oculta una apuesta negativa: alejarse de la matemática para acercarnos a algo netamente artesanal. En donde todo depende de la «experiencia» y del buen trato con otros. Esto que es real y útil —la comunicación con las personas— se ha exagerado a tales niveles que muchos informáticos (desarrolladores de software, en particular) no conocen los métodos formales. Y si lo conocen, los desprecian. «Las matemáticas no son necesarias para programar», «las habilidades blandas son lo importante», «no es necesario entender cómo funciona algo porque para eso tenemos bibliotecas», así podría continuar enumerando frases que esconden un desprecio por la precisión: o para ser más específico: por la teoría.
Antes bien, esto no quiere decir que esas frases no sean reales, es más bien, un tema de grado y de no tener la capacidad de ver más allá del típico software. Por ejemplo, la primera, si es verdad que no necesitas matemáticas para poder programar una simple aplicación de frontend que muestra los gráficos del precio de una moneda, distinto es el caso si se quiere programar una aplicación web que deba generar origamis y presentarlos y manipularlos en 3D. Ambas requieren un trabajo del frontend pero con una distinta dificultad.
Otra postura es la defensa de los métodos formales que oculta una ingenuidad: pensar que es posible añadir métodos formales a todo tipo de software en pos de continuar con el sueño de eliminar por completos los bugs. Esto, sin duda, es absurdo porque incluso si un programa no tiene errores, no asegura que haga lo que dice el requerimiento.
No todo son problemas de compilación, claro. Hay problemas semánticos: entender realmente lo qué se debe hacer. Un problema más humano que informático. Es en este punto que el área ingenieril ha superado a la parte formal, pues dado que todo varía y, además, es dinámico, los requerimientos pueden cambiar día tras día. ¿Y cómo nos preparamos a esto? A través de una flexibilidad extrema, lo que hoy en cuanto conocemos como metodologías ágiles.
Los lenguajes de especificación como TLA+ y Coq sirven para hacer más robustos y formales ciertas partes del desarrollo de software. Eso es la verificación formal. Por supuesto, mostrar una tabla con datos de un cliente en una web no requiere de una verificación formal; en cambio, el sistema de piloto automático de un avión sí que lo necesita. La verificación formal es factible en piezas de código muy específicas, acaso críticas y muy bien definidas y sin ambigüedad en el requerimiento. Sin olvidar, claro, que no es posible hacer todo el desarrollo de software así, dado que es demasiado costoso y complejo.
El software depende de muchas cuestiones, es dinámico, es frágil, es proclive a cambios, pero no debemos olvidar que el desarrollo de software no es solo un tipo de software: hay otras áreas en donde seguir una estrategia más cercana a las matemáticas sea lo más útil y más adecuado. La formalidad no debe perderse porque es ahí donde podremos encontrar algo de verdad.
Conoces mi postura: un informático trabaja con invariantes. Debemos ser analistas antes que programadores y debemos ser arquitectos ante que programadores, y debemos gozar programando.
Y la otra postura: No entiendo esta forma de solucionar problemas basada en seguir un algoritmo voraz (no pensar más allá, no tener un plan: simplemente pensar en la siguiente iteración)... cuando estaba en segundo de carrera estudiando este tipo de algoritmos nunca pensé que se aceptaría como el "alma máter" agile mediante.