La complejidad de los desarrollos software. El programa de 40 líneas.

Es sorprendente la solidez que los arquitectos confieren a sus edificios si la comparamos con la cantidad de sistemas informáticos que caen todos los días.

Es cierto que los arquitectos también cometen errores, sin embargo ellos obtienen casi siempre unos edificios sólidos que no se derrumban, mientras que los informáticos obtenemos con frecuencia programas o aplicaciones informáticas “inestables”. ¿Porqué ocurre esto?. ¿Porqué muchas veces los sistemas informáticos que desarrollamos carecen de solidez?.

Con estas premisas se pueden considerar dos planteamientos distintos: a) que los ingenieros de la rama informática estamos menos capacitados que los arquitectos, o b) que la complejidad de un sistema informático es mucho mayor que la que en un principio pudiese parecer, mayor incluso que la complejidad de mantener un edificio en pie.

En cuanto al punto a), es poco probable que los arquitectos estén mejor preparados que los ingenieros informáticos, puesto que nuestra preparación en términos de tiempo y esfuerzo es similar (y creo que ambos hemos demostrado nuestra valía con nuestro título universitario).

¿Puede ser entonces que el desarrollo de un sistema informático sea una tarea sumamente compleja?

Personalmente pienso que muchos sistemas informáticos tienen una complejidad elevada, intrínseca a la funcionalidad para la que han sido diseñados. No obstante, dudo mucho que desarrollar un sistema informático sea más complejo que mantener un edificio en pie.

Cuando hablo de desarrollar un sistema informático no me refiero a desarrollar “todo” el sistema, desde los microchips hasta el ventilador de refrigeración, sino exclusivamente a desarrollar el código de una aplicación informática, me estoy refiriendo exclusivamente al software.

He participado en varios proyectos de desarrollo de software y he conocido otros muchos proyectos en funcionamiento, y en la mayorí­a de ellos he tenido la sensación de volver a inventar la rueda, de estar rehaciendo un trabajo 100 veces hecho. ¿Cuantas veces hemos escrito código para acceder a una Base de Datos? ¿Y cuantas hemos escrito código para presentar un formulario por pantalla? … Pues eso, decenas de veces, como mínimo.

¿Por qué se hace esto? ¿Por qué cada vez que arranca un nuevo proyecto de desarrollo software la tendencia es escribir el código desde la primera línea hasta la última?

• ¿Por qué cada vez volvemos a estructurar nuestro código en las famosas tres capas de presentación, lógica de negogio y acceso a base de datos (creo que les han cambiado el nombre muchas veces, pero siguen siendo esencialmente lo mismo)?
• ¿Por qué cada vez volvemos a escribir el mismo código para acceder a la base de datos?
• ¿Por qué cada vez volvemos a diseñar desde cero las pantallas de las interfaces gráficas del usuario?

La mayorí­a del código que escribimos lo hemos escrito ya mil veces, ¿por qué lo hacemos una vez más? ¿qué queremos conseguir? ¿pensamos que vamos a aprender algo nuevo la vez mil y una?

Pero eso no debería ser preocupante, después de todo, si haces algo muchas veces acabas por hacerlo bien y rápido. La cuestión de fondo es que esto no ocurre así. A veces, lamentablemente, ocurre que un código al que estás acostumbrado y que has hecho decenas de veces contiene errores, has vuelto a inventar la rueda sólo que en este caso ha salido una rueda que gira defectuosamente.

Desde mi punto de vista el problema de fondo es empezar a escribir todo el código desde cero. Empezar de cero cada vez, inventar la rueda cada vez.

Con nuestra tecnología, nosotros proponemos desarrollar una aplicación informática sin volver a hacer lo que ya está hecho, sino desarrollar la aplicación haciendo sólo lo nuevo, lo que es diferente y particular de cada aplicación en concreto. Así pues, sugerimos desarrollar aplicaciones informáticas con no más de 40 líneas de código.

Evidentemente, un programa de 40 líneas nunca va a fallar puesto que puedes ver todas las líneas en la pantalla al mismo tiempo y detectar cualquier error. Sin embargo, cualquier línea que se escriba a partir de la 40 es propensa a contener errores. La metodología tradicional se empeña en seguir construyendo aplicaciones escribiendo miles de lí­neas que ya han sido mil veces hechas, probadas y corregidas, y que las volvemos a empezar de cero, y peor aún, … que a veces fallan.

Si los arquitectos hubiesen de calcular todos los elementos de la estructura de su edificio desde cero, serían incapaces de poner la primera piedra. Sin embargo ellos no lo hacen y, a diferencia de los nuestros, sus edificios sólo se caen en rarí­simas ocasiones. Para hacer su trabajo los arquitectos cuentan con una base “sólida” de herramientas y componentes que ya conocen, y con los que simplifican un trabajo que es sumamente complejo.

Las herramientas ideales que necesitarí­amos los informáticos serí­an aquellas que nos diesen una base sólida y 100% fiable, que incluyese el código 100 veces hecho de acceder a base datos y pintar la interfaz gráfica del usuario, y utilizando esa base sólida diseñar y construir tantas aplicaciones a prueba de bombas como deseemos.

Si consiguiesemos que el código de cada nueva aplicación fuese de no más de 40 lí­neas, podrí­amos prácticamente garantizar que la aplicación estuviese libre de errores.

Puede sonar como una tonterí­a, pero la tecnologí­a que hemos desarrollado para la Plataforma CRISOPEYA persigue ese objetivo. Definir y construir aplicaciones para gestionar información con unos ficheros que, todos juntos, apenas superan las 20 lí­neas, porque esas 20 lí­neas son las nuevas, y el resto es el código mil veces hecho que ahora se usa como base sólida.

Así pues, pensamos que la vía para conseguir aplicaciones informáticas estables es utilizar herramientas fiables que reduzcan la complejidad del desarrollo a realizar, limitando este desarrollo a lo estrictamente nuevo, diferente y específico.