Un reclamo por la simplicidad

En los últimos días, poco más de una semana, varias notas convergen a un problema que -a guiarnos por estos comentarios- parece que van alcanzando un tope: la creciente complejidad que resulta del diseño del software, al menos siguiendo la línea predominante publicada (No digo el promedio común de la industria, que sospecho que ha de ser mucho más humilde y próximo al Duct Tape Programmer de Joel Spolsky)
El primero en hablar es el mencionado Joel Spolsky, que presenta de ésta manera el problema:

Here is why I like duct tape programmers. Sometimes, you’re on a team, and you’re busy banging out the code, and somebody comes up to your desk, coffee mug in hand, and starts rattling on about how if you use multi-threaded COM apartments, your app will be 34% sparklier, and it’s not even that hard, because he’s written a bunch of templates, and all you have to do is multiply-inherit from 17 of his templates, each taking an average of 4 arguments, and you barely even have to write the body of the function. It’s just a gigantic list of multiple-inheritance from different classes and hey, presto, multi-apartment threaded COM. And your eyes are swimming, and you have no friggin’ idea what this frigtard is talking about, but he just won’t go away, and even if he does go away, he’s just going back into his office to write more of his clever classes constructed entirely from multiple inheritance from templates, without a single implementation body at all, and it’s going to crash like crazy and you’re going to get paged at night to come in and try to figure it out because he’ll be at some goddamn “Design Patterns” meetup.

And the duct-tape programmer is not afraid to say, “multiple inheritance sucks. Stop it. Just stop.”

Pocos días después, Rodrigo Corral, en su blog, toma el problema desde el punto de vista de la complejidad desbordada, invirtiendo una frase que Microsoft popularizara ( ‘hasta donde quieres llegar hoy?’), y convirtiéndola en una expresión de cansancio (¿Hasta donde podemos llegar?):

Un anuncio de Microsoft decia: ‘hasta donde quieres llegar hoy’ o algo así, pero la pregunta es más bien ¿hasta donde puede llegar la ingeniería del software?. Comenta Gustavo, vecino de blog y uno de los grandes de Sharepoint (y no solo de Sharepoint) que cada vez la complejidad de los proyectos de Sharepoint es mayor, tanto como para que en muchas ocasiones lo mejor sea esconder la cabeza como un avestruz. Yo lo se bien, pase de conocer a fondo la versión 2003 a caer en la sima de la transición a 2007. Hace tiempo que deje de ser un experto en Sharepoint, si es que alguna vez lo fui del todo, el salto a la versión 2007 me supero, demasiada complejidad para un humano mortal.

En mi opinión lo que Gustavo comenta no solo está ocurriendo en Sharepoint. Es un problema generalizado, cada vez más voces importantes del mundo de la ingeniería de software se preguntan si no hemos alcanzado un punto de singularidad en el que la complejidad de los problemas a resolver se ha incrementado más allá de lo manejable.

[...]Los sistemas son cada vez más complejos, exponencialmente más complejos, pero las herramientas han cambiado solo sutilmente. Ya nos sabemos eso de KISS, si, pero no es suficiente. En esencia, desde que Grace Murray, almirante de la marina estadounidense y probablemente la mujer más influyente en la historia de la ingeniería de software, invento el compilador, no se ha producido un cambio cualitativo importante en la forma en que se hace software. Codificar, compilar, depurar. Solo se han añadido billones de horas hombre al desarrollo de software. Fuerza bruta. El problema es hasta donde escala esta aproximación... cada vez parece más que hemos tocado techo. Hay quien incluso ha puesto nombre a este problema: el dilema de la divergencia del software. Ahí es nada…

[...]Yo personalmente soy pesimista. Todos los intentos de atajar la complejidad que hemos realizado han sido en vano. Los patrones parecían prometedores, pero aunque útiles no han supuesto una revolución. Las herramientas 4GL se postularon como una especie de bálsamo de Saxafrax, que se quedo en nada ¿alguien usa 4GL?. Las herramientas de modelado… en fin… esperemos a Oslo, pero mucho me temo que tampoco será mágico… y necesitamos mucha magia. Las herramientas no van a ser la solución al problema. Fijaros, llevo programando desde VB3.0. En la caja de todas la herramientas de programación que he usado desde entonces ponía algo parecido a ‘mejora tu productividad un X%, siendo X > 20’. He conocido VB4, VB5, VS6, VS2001 (productividad con esteroides gracias a .NET), VS2003… hasta VS2010. Si cada versión hubiese mejorado mi productividad lo que su marketing prometía ahora yo sería capaz de programar con la mente.

Finalmente, hace dos días, leo a Charles Young hablando de StreamInsight, de tal forma que representa claramente lo que Rodrigo comenta:

There are a couple of gotchas. First, don’t do what I did while experimenting. I created a QueryTemplate and serialised it to XML. I then tried to deserialise it as a second, identical, QueryTemplate in the same Server instance. I got back an InvalidDefinition error. It seems you can’t have identical QueryTemplates in a single StreamInsight Server instance.

The second thing to note is that the serialised QueryTemplate does not contain fully qualified references to your event types. You still have to define the event types in your application by calling the CreateEventType method. If you plan to store QueryTemplate XML in some custom repository, you will also need to store the fully qualified names of the .NET types your have defined for your events. Of course, you will also need to ensure that these types are available at runtime.

Much the same argument applies to adapters. The QueryTemplate XML does not contain any information on which input and output adapters you want to bind to your query. However, once you realise that your QueryTemplates are serialisable, it is simple to work out how you might store and manage the template in some repository together with event type and adapter information. All this information, taken together, defines the StreamInsight concept of a query. You can write code to extract it from the repository at run-time and run the query.

The current CTP is just a glorified SDK. Will Microsoft provide a repository and tooling in the release version? I have no idea. Given the freedom StreamInsight offers in terms of event definition, and given the fact that the engine can be hosted in custom applications, it is difficult to see how Microsoft could provide a totally generic end-to-end solution that would support externalisation of queries in any and all circumstances. They could provide a repository and API, and leave it to developers to write the code to exploit the repository. However, you would still need to write the LINQ together with code to create QueryTemplates and extract and upload XML to the repository.

...And so on...

En fin, quisiera sin embargo terminar diciendo que quizá lo que ha alcanzado un tope es el modo de encarar la construcción del software. Dada la complejidad, pretender abordarlo a nivel de campo no será materialmente posible. Disintiendo con Rodrigo, éste es el momento de marchar a los 4GL, aquél paradigma sistemáticamente descartado por los enamorados del código, especialmente si es el más novedoso, y elevar el nivel de abstracción. Mucho se ha hablado aquí de ésto, y no es necesario ser redundante.