Si alguien le dice que programar es fácil: podríamos afirmar —sin miedo a equivocarnos— que este personaje cae en al menos dos faltas: nunca ha trabajado en sistemas escalables o confía arrogantemente en su conocimiento. Ambas opciones se reúnen al amparo de la ignorancia, aunque, la primera por desconocimiento, y la segunda por tontería. El desconocimiento se cura aprendiendo, en cambio, para la tozudez no hay remedio evidente, acaso, porque los necios jamás han visto con buenos ojos admitir que están equivocados.
Es, pues, improbable rescatar algo positivo de los necios, que a través de sus grandes malabares sostienen sus carencias de aprendizajes, abandonando toda posibilidad de resarcirse consigo mismo, nada más queda dejarlos con sus faltas de ideas, e irse a otro sitio. Lejos, de ellos, claro.
Ahora bien: dejando de lado a los necios que suficiente daño se infieren a sí mismo. Programar es una tarea difícil. En efecto, cualquier actividad de escritura lo es, ya sea usando un lenguaje formal o un lenguaje natural, ordenar los símbolos para que tengan un sentido y, en el caso de la programación, pueda resolver un problema: es una tarea ardua, con errores esperables.
«Con cada nueva línea de código aumenta las probabilidades de errores» es un dicho común entre los desarrolladores, resopla en nuestros oídos cada vez que añadimos nuevas funcionalidades, la cual entraña algo más profundo: «Convivir con errores es parte del oficio». Y aunque esto último puede dar pie para otro debate:1 mas ningún software interesante se construye con pocas líneas de código: ni los bellos scripts de AWK, ni los crípticos scripts de Perl, que, aun cuando su utilidad sea total, un software empresarial es algo muy diferente: supone una cadena de requerimientos que se traducen en funcionalidad que, a su vez, se traducen en más y más código (incluso en diferentes lenguajes de programación).
Obteniendo de esta forma un bello dilema: si los software interesantes no son breves ni concisos, ni están libres de errores, «¿para qué programar?». A esto se atañe otra cuestión: incluso si tuvieras las habilidades para crear buen software, eficiente y seguro, inevitablemente, para añadir más funciones, tendrás que añadir nuevas personas que te apoyen. Nadie construye una pirámide solo. Y las probabilidades de errores aumentan.
Ante tal condena solo nos queda seguir intentando avanzar entre piedras y barro, y una que otras zambullidas que nos limpian y nos consuelan.
El debate se puede reducir a: no todo software es igual. Hay algoritmos que se diseñan usando métodos de verificación formal en donde las probabilidades de errores no existen, y si existieran, ocurrirían fuera del entorno en donde se hizo la verificación formal (por ejemplo, una falla en el hardware). El punto en contra: la verificación formal es compleja de realizar, también en cuanto a tiempo. Ésta, por lo general, se recomienda emplearla en partes críticas del código, y en entornos concurrentes y distribuidos.
Hay tantos matices en la aseveración de “programar es fácil” como en la de “jugar a fútbol es fácil”. Programar como tal es sencillo, simplemente:
puts “Hola mundo!”
Ahí tienes tu primer programa. Ahora, a lo que creo que te refieres es a crear software empresarial. Porque no creo que te preocupe mucho que un código Visual Basic en una celda de Excel sea o no escalable.
El diseño de software a través de una organización de conceptos es una tarea ardua que como bien dices se intensifica con la llegada de nuevas características. Las pruebas sólo pueden ayudarnos a encontrar fallos o no volver a caer en los ya encontrados (pruebas de regresión), mientras que una prueba formal pueda analizar parte del dominio del problema, un algoritmo a veces es simplemente parte de un flujo de datos mucho mayor y sobre todo variante. Realizar pruebas formales en software empresarial no suele ser la norma.
No obstante, programar es mucho más que desarrollar un software. Programar un mod para tu juego favorito, un pequeño guion para correo electrónico o algo elaborado dentro de Excel también es programar y aún careciendo de todos los rituales instaurados para el desarrollo empresarial o académico, no se puede negar su valor intrínseco que acerca a esos neófitos a querer aprender más popularizando así la creación de código.