¿Es PaaS nuestra bala de plata?

El desarrollo de software es difícil. Podríamos tener los mejores desarrolladores del mundo, los procesos de desarrollo más ágiles, y las mejores herramientas de desarrollo disponibles, y aún así seguiría siendo difícil. Esto es así por la naturaleza del software, por su esencia. ¡La única manera de no tener problemas desarrollando software es no desarrollándolo! ¿Podría ser que las modernas tecnologías de PaaS son la bala de plata que necesitamos para matar al hombre lobo del desarrollo de software?

Begegnung im Haus (Werwolf von Neuses) via Wikimedia Commons

En su obra clásica, “El Mítico Mes Hombre” (“The Mythical Man Month”), Fred Brooks nos dice por qué es imposible encontrar una “bala de plata” para el desarrollo de software (Brooks 1995). Durante décadas los desarrolladores de software han estado buscando esa bala de plata mágica necesaria para hacer que el software sea más fácil de desarrollar. Sin embargo, ¡el desarrollo de software es todavía muy difícil! Su argumento sobre por qué nosotros no encontraremos una tal bala y el desarrollo de software continuará siendo difícil yace en la distinción entre la complejidad accidental y la complejidad esencial del software.

La complejidad accidental del software se refiere a los problemas en la codificación o programación del software. Es decir, los problemas en asegurarse de que el software ofrece las funcionalidades que se supone debe ofrecer, que funciona bien, y desarrollar lo más rápido que podamos. A medida que ha avanzado la tecnología hemos sido capaces de reducir la complejidad accidental y hacer la programación más fácil. Escribir en lenguaje ensamblador era mucho más fácil que la perforación de tarjetas. Los entornos 2GL y 3GL eliminaron la complejidad de escribir código ensamblador. Ya hoy existen muchas interfaces que casi sólo hacen uso del mouse (drag-and-drop) para programar, casi sacando la escritura de código de la ecuación.

Tal y como Kevin McEntee señaló en su keynote en Cloud Connect hace unas semanas, la complejidad accidental ha sido generacional. Hoy la complejidad puede estar más en “correr” el software que en “desarrollarlo”. Como dijo Kevin, hoy estamos preocupados por si nos quedamos sin espacio, si el equipo es obsoleto, si tenemos la potencia y refrigeración suficientes, entre otros temas. Estoy seguro de que la industria va a encontrar una salida y resolver estos problemas en el futuro cercano, sobre todo con el advenimiento de la computación en nube.

Sin embargo, aún tenemos la complejidad esencial del software, que Brooks sostiene es la fuente de la raíz de nuestros problemas y se relaciona con las propiedades inherentes del software: la complejidad del sistema, la conformidad, la mutabilidad, y la invisibilidad. Hay poco que podamos hacer acerca de estos.

Acerca de la complejidad del sistema, si definimos un “sistema complejo” como “uno compuesto por un gran número de partes que tienen muchas interacciones” (Simon, p. 183-184), entonces el software es complejo por definición. Adicionalmente, dada la naturaleza jerárquica de software (ej., las rutinas se componen de sub-rutinas, clases de objetos tienen subclases, servicios web llaman a otros servicios web), es fácil para el software evolucionar rápidamente hacia sistemas complejos: “los sistemas complejos evolucionarán desde simples sistemas mucho más rápido si existen formas intermedias estables” (Simon, p. 196). El crecimiento en funcionalidades también aumenta el alcance del software (su número de sub-sistemas, p. 187), lo que aumenta el número de enlaces necesarios entre las partes que deben ser atendidos. El software es complejo, y es difícil hacer un seguimiento de todas sus partes móviles. Podríamos afirmar que la modularidad reduce la complejidad, pero eso es un arma de doble filo: se disminuye a nivel de módulo y pero se aumenta a nivel del sistema integrado, ya que hay más piezas que deben integrarse.

Conformidad se refiere al hecho de que las aplicaciones de software no existen en forma aislada. El software tiene interfaces (i.e., GUIs o APIs) para interactuar con entidades fuera de su dominio, y hay poco que un desarrollador de una aplicación de software puede hacer por controlar a estas entidades ajenas. Una vez más, no hay manera de cambiar esto; es parte de la esencia del software. La mutabilidad está estrechamente relacionada con la conformidad y se refiere al hecho de que el software no es un elemento estático porque sus requisitos nunca son estáticos. Así como el mundo alrededor de una aplicación de software cambia, también debe cambiar el software. Esto es particularmente cierto cuando se trata de satisfacer los requerimientos de los usuarios finales, que en muchos casos ni siquiera saben lo que quieren y cambian sus necesidades en cada lanzamiento. No podemos fijar ni prevenir el cambio en el mundo alrededor de nuestras aplicaciones. Por último, la invisibilidad se refiere a la naturaleza intangible de software. No podemos “ver” o “tocar” el software. Ni siquiera las técnicas de modelado más sofisticadas pueden representar adecuadamente todas las partes móviles de una aplicación de software. “La realidad del software no está inherentemente definida en el espacio” (Brooks 1995).

Dado que la única forma de evitar la complejidad esencial del software es no desarrollándolo, podríamos pensar que comprar un software empaquetado o suscribirse a un servicio SaaS sería una gran solución. No obstante, todo lo que haríamos al adquirir este software es pasarle los dolores de cabeza a otra persona. El proveedor de software todavía tiene que lidiar con todos los problemas mencionados anteriormente. Por otra parte, nosotros, como usuarios, nos convertiríamos en la fuente de muchos de los desafíos del proveedor.

Cuando escuché de PaaS por primera vez, pensé que sería un gran paso para resolver las dificultades del desarrollo de software. Después de todo, lo que vendenForce.com, Heroku, GAE y otras ofertas de PaaS, es que hacen la vida de los desarrolladores mucho más simple mediante la abstracción de la infraestructura subyacente. No obstante, esto no es más que una nueva solución a la complejidad accidental relacionada con la infraestructura. El desarrollador de software aún debe hacerle frente a la complejidad esencial. Entonces, ¿podría haber alguna otra forma de brincarnos o eludir el proceso de desarrollo de software? No del todo, pero nos estamos acercando.

En Cloud Connect, en parte gracias a una discusión con Krishnan Subramanian, aprendí sobre OrangeScape, una solución de “PaaS visual” (como lo describen ellos) que permite a los usuarios finales programar y dar de alta a sus propias aplicaciones de software. ¿Cuál es el beneficio de esto? Veamos de nuevo a las características esenciales del software. El IT stack necesario (ej., un LAMP stack con su hardware) sigue siendo muy complejo. Sin embargo, el usuario, ahora desarrollador también, no se preocupa por él. El usuario sólo se preocupa por la complejidad de sus requerimientos. Además, ¿quién mejor que el usuario final para decidir cómo debe ser una interfaz gráfica (GUI)? En este sentido la conformidad se mitiga; aunque aún hay que integrar la aplicación con otros sistemas. El impacto de la mutabilidad también se reduce. En lugar de tener a un desarrollador intentando capturar y satisfacer los requisitos cambiantes de los usuarios finales, ¿por qué no tener al usuario final satisfaciendo sus propios requisitos? Todavía deberemos tener en cuenta la mutabilidad del contexto técnico, pero esta mutabilidad será menos ambigua y difusa que la mutabilidad ocasionada por el usuario. Por último, la interfaz agradable y familiar (que se parece a Excel) de OrangeScape permite a los usuarios finales visualizar sus propios procesos de software, lo que reduce el impacto de la invisibilidad de software. ¡Esto es como un Scratch para aplicaciones empresariales!

Vale la pena hacer una pausa aquí para señalar que esta no es la primera vez que las aplicaciones de software facultan a los usuarios finales a trabajar por su cuenta. Herramientas para generar reportes (ej., Crystal Reports) y otras aplicaciones de inteligencia de negocios han existido por mucho tiempo y han reducido la necesidad de tener a un desarrollador para generar un informe basado en un conjunto de datos. Estas herramientas permiten al usuario, que es quien mejor entiende lo que quiere ver en un informe, desarrollar el informe por su cuenta. Lo que es nuevo en la solución de OrangeScape es que ahora los usuarios están implementando la parte lógica de negocio de software. Ellos construyen las aplicaciones que generan los datos, no sólo los reportan.

No voy a decir aquí que las ofertas de PaaS modernas son la bala de plata. Las propiedades esenciales inherentes de software aún están allí. Acercar al usuario final un poco más al proceso de desarrollo es sólo la mitad del problema y no hay que olvidar que para lograr esto alguien tiene que desarrollar la plataforma PaaS primero. Sin embargo, es bueno saber que estamos resolviendo una parte del problema. Nuestra búsqueda por la bala de plata continúa.

Brooks, Frederick P. (1995) The Mythical Man Month: Essays on Software Engineering. Addison-Wesley Professional; Anniversary edition. Chapters 16-17. Simon, Herbert A. (1996) The Sciences of the Artificial. MIT Press; 3^rd Edition. Chapters 7-8.