¿Es tiempo de volver a la simplicidad?

En estos días Ted Neward escribió un interesante post “Agile is treating the symptons, not the disease” donde citaba una frase pronunciada por Billy Hollis en el Patterns and Practice Submit de esta semana, en Redmond. Leo ahí:


“A lot of software written back in the 90’s was written by 1 or 2 guys working for just a few months to slam something out and see if it was useful”


“The problem is the complexity of the tools we have available to us today preclude that kind of software development.”


Yo veo el problema más asociado con tecnologías que con las herramientas. Puedo tomar como ejemplo los servicios web. Para mí, los servicios web no son una herramienta como lo son una librería, un compilador o una IDE. Los servicios web son tecnología. Muchas de las herramientas que usamos (Eclipse, Visual Studio, …) luchan contra la complejidad de las tecnologías. Uno o dos programadores todavía pueden crear una maravillosa librería de código abierto. Pero traten de escribir con el mismo equipo una aplicación empresarial que involucre base de datos, comunicaciones, seguridad, administración, instrumentación, y más. Hay tantos detalles en las tecnologías que usamos para implementarlo, que la complejidad de cualquier aplicación no trivial puede (y frecuentemente es) abrumadora.


Volvamos a los servicios web. ¿Visitaron la página de la Wikipedia sobre el tema, recientemente? Encontrarán docenas de especificaciones. Podrían pasar semanas o meses, tratando de entender y comprender todas los detalles técnicos que se encuentran en WS-Trust, WS-Addressing, WS-Transaction, WS-PutYourWordHere. Pienso que la adopción de estilos REST es una reacción contra esa locura (estilo a la REST, no veo tan adoptado los principios REST, o lo que se llama RESTFul). De vez en cuando, hay librerías que acuden a nuestra ayuda, y otras veces aún esas librerías fallan. Mi ejemplo preferido de un intento fallido de ocultar la complejidad de los servicios web, es Windows Communication Foundation (WCF). Escribí sobre el tema en Windows Communication Foundation configuration madness.


La complejidad en software no es mala por sí misma. Puede llegar a ser buena. El software influye en casi toda actividad humana. La popularidad de Internet, alimentada por una “killer application” como la World Wide Web, influye en las actividades nuestras de todos los días. Como desarrolladores de software, estamos contribuyendo a ese progreso. No perseguimos estar en nuestra zona de confort sino que buscamos agregar valor a nuestro software. Y si eso implica mayor complejidad, no debemos evitarla.


En la actualidad, los requerimientos de los clientes son más desafiantes: acceso de múltiples usuarios, en cantidad masivas, escalabilidad, procesamiento distribuido para cumplir con la carga, disponibilidad en línea 24 horas, 7 días a la semana. Todos son requisitos que usualmente se incluyen en las aplicaciones empresariales modernas. Y no hay soluciones simples para cubrir todos esos temas.


Dicho todo esto, veamos que la complejidad está con nosotros pero puede ser combatida. Yo paso gran parte de mis horas de trabajo enseñando programación, y el resto del tiempo, lo paso desarrollando sistemas. He sufrido la complejidad del estado actual de cosas tanto en la enseñanza como en el desarrollo de software. La cantidad de detalle a tener en cuenta (seteo de ORMs, configuración por inyección de dependencias, preparación de los tests, librerías de mocks, configuración de WCF o JBoss o EJBs….) es tan grande que nuestras mentes están perdidas en el medio de tal jungla de detalles.


¿Recuerdan la “Era Petzoldiana” (en honor a Charles Petzold, autor de libros de programación para Windows)? Cantidad de líneas de código a escribir para producir un simple programa “Hello world” que corriera en Windows. Entonces, en esos años, apareció Visual Basic. Fue un modo efectivo de esconder la complejidad de la API de Windows, salvando a toda una generación de desarrolladores de pelearse con handles y valores LONG donde las coordinadas del mouse venían en mensajes de Windows. Esa API de Windows, así desnuda, era (y es) un infierno, un verdadero infierno.


¿Recuerdan cuando era necesario leer VTOCs en discos de IBM? ¿Escribir Job Control Language? ¿Escribir macros en ensambladores? Para cada una de esas herramientas, aparecieron otras nuevas que contribuyeron a ocultar la complejidad usando un “viejo truco”: elevar el nivel de abstracción. En vez de pensar en registros y sectores, comenzamos a manejar variables y comandos SQL.


Yo pienso que fue al final de los ochenta, principios de los noventas, cuando el desarrollo de software en el ámbito de las PC alcanzó el tope en la razón poder/complejidad. Ejemplos que se me ocurren: Turbo Pascal, Visual Basic, Access. Con ellos, teníamos gran cantidad de poder de programación acompañado de baja complejidad. Desde entonces, veo que estamos en caída libre. El “viejo truco” de “elevar el nivel de abstracción” no fue adoptado de nuevo: todavía estamos construyendo software usando lenguajes de tercera generación, lo que podríamos considerar los macro ensambladores de los sesenta.


Como decía, una forma de escapar de este estado de cosas es ir al siguiente nivel de abstracción. Ya alguna vez hemos olvidado manejar registros e instrucciones Branch and Link Register, y hemos adoptado lenguajes de programación generales. Ahora, necesitamos escribir software en un nivel más alto. Mi apuesta: Domain Specific Models y Domain Specific Languages. Pero es sólo una apuesta. Usando DSLs, DSMs, generación de código (¿se dan cuenta que cada día que usan un compilador C# o Java, están “generando código” AHORA MISMO?) podremos apalancar la tecnología existente, ocultando la complejidad subyacente.


Con tantos lenguajes, librerías, tecnologías a usar, no hay una simple solución para ocultar todo este lío. Noten que hay varias tipos de complejidad. Una es la complejidad en los requerimientos de los clientes: lógica de negocios, requerimientos functionales y no funcionales. Eso está bien, es parte de nuestro trabajo. Pienso que las metodologías ágiles están atacando ese tipo de complejidad. Pero también existe la complejidad tecnológica. Y ese tipo de complejidad, debería ser más atacada. Debemos parar esta vuelta a la era Petzoldiana (recientemente, encontré el concepto de Complejidad Accidental, en una charla de Rich Hickey talk (hmmm… creo que él la llamaba complejidad incidental). Leo en la página de Wikipedia accidental complexity:


Accidental complexity is complexity that arises in computer programs or their development process (computer programming) which is non-essential to the problem to be solved. While essential complexity is inherent and unavoidable, accidental complexity is caused by the approach chosen to solve the problem


)


Otros posts interesantes, disparados por el inicial de Neward:


El de Jeffrey Palermos Response: “Agile is treating the symptoms, not the disease” by Ted Newardç
Uno de Phil Haack Software Externalities
La respuesta de Ted Neward a Haack Haacked, but not content; agile still treats the disease 


Tengo tanto para comentar de estos posts. Pero por ahora, sigo con el tema inicial.


Me gustaría recordar un punto más: la complejidad no es el único desafío en el desarrollo del software. Todo proyecto exitoso tiene dos desafíos: enfrentar la complejidad y manejar el cambio. Son esos los problemas que las metodologías ágiles nos ayudan a enfrentar: combatir la complejidad con “baby steps”, pasos de bebé. Hay que recordar cómo se come un elefante: pedacito a pedacito. Y nos ayudan a no temerle al cambio, al contrario: tenemos que abrazarlo, adoptando disciplinas ágiles que disminuyan el costo de cambiar en el medio del desarrollo.


Otro punto: con la adopción de Internet, nuestra actual cultura de desarrollo de software está floreciendo, poblada de ideas, implementaciones de referencia, librerías y herramientas de código abierto, patrones y estilos de arquitectura, mejores prácticas, frameworks, paradigmas de programación, y lenguajes. Por ejemplo, hay una nueva camada de lenguajes dinámicos, montados sobre Java y .NET. Todo indica que la caja de Pandora ya fue abierta: no veo una forma fácil de cerrarla.


En el post de Ted Newerd que citaba al principio, él escribió:


Let me rephrase Billy’s talk this way: Where is this decade’s Access?


Tengo algunas ideas al respecto, sobre cómo podría ser el próximo Access. Pero quedará eso planteado para otra clase.


Nos leemos!


Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

This entry was posted in 3463. Bookmark the permalink.

3 Responses to ¿Es tiempo de volver a la simplicidad?

  1. Cerebrado says:

    Hola Angel. Es justamente lo que había planteado, pero orientado mas a lo técnico en http://softcero.blogspot.com/2009/09/ddd-no-es-todo.html

    Si a la complejidad de las aplicaciones le agregamos complejidad innecesaria en el desarrollo… tenemos complejidad al cuadrado.

  2. Amigo Angel:

    Aunque usted piensa que no lo leo, lo leo siempre :-) y este post me encanto, comparto casi en su totalidad :-))

    Un abrazo desde Traslasierra
    Eugenio

  3. Angel, buenos dias, creo que es bueno leer de vez en cuando las leyes de simplicidad de Maeda…

    http://lawsofsimplicity.com/category/laws?order=ASC

    Saludos
    Andres

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>