Hace un mes Robert C. Martin (Uncle Bob) publicó un post que, como muchos de los que escribe, generó bastante atención. Lógico, teniendo en cuenta que es el padre de Clean Code y uno de los abanderados del movimientos Software Craftmanship que tantos adeptos tiene. Quizá esa influencia que tiene sobre la opinión de mucha gente merezca dedicar algo de tiempo a analizar lo que dice en su post.

Os recomiendo que leáis el post original antes de continuar. Sólo os llevará un par de minutos y os permitirá contextualizar la discusión. Si sois demasiado perezosos para eso y confiáis en mi resumen (cosa que no deberíais hacer), el post viene a decir los siguiente:

All we are really doing is reinventing the wheel, over, and over again. (…)
Progress in software has followed a logarithmic growth curve. In the early years, progress was stark and dramatic. In later years the progress became much more incremental. Now, progress is virtually non-existent. (…)
New languages aren’t better; they are just shiny. And the search for the golden fleece of a new language, or a new framework, or a new paradigm, or a new process has reached the point of being unprofessional.

Vamos, que está todo el pescado vendido.

Que ya no hay margen para grandes avances en el mundo del desarrollo de software. Que la forma en que desarrollamos software hoy en día es la mejor, nuestras herramientas (él habla concretamente de Eclipse e IntelliJ) son las mejores, y nuestros lenguajes actuales los más adecuados. Intentar encontrar mejores soluciones es un esfuerzo futil que no merece la pena, y una actitud que podemos considerar poco profesional.

No te dejes llevar por las modas

Lo que hay que hacer, según Robert C. Martin, es aprovechar lo que ya tenemos. Conocer unos cuantos lenguajes de los que ya existen, saber sacarle partido a las herramientas que hemos construido y empezar a desarrollar software que resuelva problemas de verdad, no que dé vueltas una y otra vez sobre las mismas cosas.

Es fácil empatizar con el mensaje. Especialmente si eres de los que está más o menos al día en este sector y estás cansado de ver modas que van y vienen, de lenguajes que no aportan nada nuevo y de librerías que desaparecen antes de que te dé tiempo a sacar la segunda versión de tu aplicación. Si además tienes contacto con el caos del desarrollo frontend, te sentirás aún más indentificado.

Yo mismo he defendido en varias ocasiones la importancia de aprender cosas fundamentales por encima de cosas novedosas, o he criticado el uso excesivo de arquitecturas de moda, y estoy de acuerdo en la necesidad de ser productivo y no estar reescribiendo nuestras aplicaciones cada dos meses sólo porque ahora tenemos un lenguaje o librería más molón.

Toda esa parte me parece bien. Me parece más peligrosa la interpretación que puedan hacer algunos, que tienen a Robert C. Martin en un pedestal, de parte del mensaje del post.

Todavía estamos empezando

Por un parte, me parece arrogante pensar que hemos alcanzado el zenit del desarrollo, y más teniendo en cuenta que estamos hablando de una disciplina que no tiene ni un siglo de antigüedad.

En el post original no se da ningún argumento real al respecto. Sí es verdad que Fortran supuso un avance mayor con respecto al Ensamblador de lo que puede suponer (si es que lo supone) TypeScript sobre Javascript, pero eso no quiere decir que no haya avance a nivel global y, sobre todo, creo que se equivoca de foco.

No se trata de comparar C# con Java. O Elixir con Ruby. O xUnit con NUnit. O React con Angular. O Visual Studio con Eclipse. Desde luego, hablar de React como un gran avance en la historia del desarrollo de software no tiene ningún sentido y no es comparable, por ejemplo, a la aparición de LISP, aunque eso no quiere decir que no sea útil, y los conceptos que ha ayudado a popularizar entre muchos de nosotros son útiles.

Pero lo más importante es que hay otras áreas en las que todavía queda mucho por avanzar. No soy futurólogo, pero hay áreas en las que creo que podemos ver mejoras a corto-medio plazo:

Sistemas de tipos y analizadores estáticos cada vez más avanzados que ayuden a detectar más errores en tiempo de compilación, o que permitan implementar soluciones de tipado gradual de forma más cómoda que en la actualidad. Esto está muy relacionado con el, a veces denostado, mundo académico, pero ese trabajo acabará llegando (como lo ha hecho en otra ocasiones) a las herramientas mainstream sin que nos demos cuenta. Entonces diremos, «mira que listo es Eclipse que refactoriza código fácilmente y nos hace ser más productivos».

Reducción del tiempo necesario para obtener feedback al hacer cambios en las aplicaciones, por ejemplo mediante herramientas que nos permitan recargar código en caliente sin perder el estado. Algo similar a lo que podemos hacer con HTML y CSS en un browser, pero aplicado a todo tipo de código. Hoy en día hay plataformas que lo soportan mejor (como Erlang), y herramientas que llegan muy lejos (como Figwheel), pero todavía no son aptas para todos los públicos y queda muchísimo margen de mejora.

Son dos ejemplos concretos de líneas de investigación, una más teórica y otra de aplicación más directa que pueden contribuir mucho a incrementar la productividad de los programadores. ¿Serían avances revolucionarios? No lo sé. Puede que no, ¿pero por qué renunciar a ellos?

El valor de iterar

Por otro lado, no acabo de comprender esa crítica a iterar sobre los mismos problemas y obtener mejoras (solo) incrementales. Reinventar la rueda es más importante de lo que parece.

De hecho, me resulta especialmente curioso que todo un artesano de software, acostumbrado a hacer katas, es decir, solucionar una y otra vez el mismo problema para perfeccionar la forma de hacerlo, no vea el valor de reinventar la rueda.

No tiene sentido reescribir una y otra vez la misma aplicación que desarrollas profesionalmente sin aportar valor adicional, pero eso no quiere decir que implementar nuevas soluciones a problemas conocidos no aporte ningún valor.

Además del valor intrínseco del aprendizaje que conlleva hacer esas implementaciones, es frecuente que cada solución tenga caraterísticas ligeramente diferentes que la haga más adecuada para cierto tipo de problemas o mas agradable para determinados grupos de usuarios.

Por seguir con los ejemplos del post original, podríamos pensar que desarrollar React existiendo Angular no tiene sentido. Bueno, y que Angular, existiendo Ember tampoco lo tiene. Sin embargo, hay diferencias suficientes entre unos y otros como para que todos puedan convivir y aportar algo al mundo de las librerías y frameworks para desarrollo web.

Con lenguajes de programación pasa exactamente lo mismo. ¿Era necesario inventar C# existiendo Java? Pues hombre, necesario, lo que se dice necesario, a lo mejor no, pero negativo tampoco es. De hecho eso ha provocado que entre uno y otro se acaben retroalimentando, pero manteniendo cada uno sus diferencias. Lo que no tiene sentido (en general) es convertir una aplicación Java a C# por el mero hecho de reescribirla.

Conclusión

La idea de no dejarse llevar por la novedad y actuar de forma responsable y profesional en nuestros desarrollos me parece importante. Ahora que muchos andan corriendo de una tecnología a otra, siguiendo modas cada vez menos duraderas, me parece un mensaje de sensatez.

Sin embargo, desincentivar la innovación diciendo que «ya está todo inventado y no hay espacio para mejora» es un mensaje muy peligroso, y más viniendo de alguien cuya opinión todavía tiene mucho peso entre muchos profesionales de este sector. Es una excusa perfecta para cerrarse en sus lenguajes, arquitecturas, herramientas y metodologías de hoy «porque con ellas ya soy productivo y lo dice Uncle Bob».

Veamos las cosas con un poco de perspectiva. No nos dejemos llevar por la modas, pero tampoco seamos tan arrogantes como para pensar que ya hemos dado con la mejor solución a todos los problemas existentes.