De lo nuevo y lo viejo

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.

8 comentarios en “De lo nuevo y lo viejo

  1. Esta vez no comparto la opinión de maese Juanma y sí estoy de acuerdo con Uncle Bob. Cada vez se notan más las muy pequeñas mejorías que ofrecen nuevos lenguajes y nuevas librerías frente al coste de desarrollo y al de aprendizaje y, en ciertos casos, frente a la necesidad de nuevas herramientas. Se está haciendo un esfuerzo gigantesco en nuevos desarrollos que no se justifica por el rendimiento que ofrecen. Además en ciertos casos incluso provocan que nos estanquemos tecnológicamente, el ejemplo más claro: el desarrollo web.

    El desarrollo web es totalmente arcaico. Nos basamos en un documento pensado para la edición de texto (tipo Word) y a partir de ahí hemos ido añadiendo parches chapuceros durante años para que su funcionamiento se acerque al de una aplicación de escritorio. En lugar de haber tomado este camino tecnológico nos deberíamos haber centrado en soluciones como las propuestas por WebAssembly.

    ¿Cuántas décadas llevamos usando HTML y todavía no está solucionado un problema tan básico como la maquetación?

    Lo importante es centrarse en la base tecnológica, ahí es donde están los verdaderos avances.

  2. El problema en este caso es que creo que muchos estamos de acuerdo pero lo expresamos de distintas formas.

    Se dice «el vaso está medio lleno, pero ojo los que se creen que hay mucha agua» y otros contestan «no, el vaso está medio vacío, pero hay gente que cree que no hay nada de agua y pasa lo que pasa».

    Obviamente, mr. Bob podría escribir los artículos con «dependes», explicando que el mundo es gris… pero así no tendría tanta repercusión.

    Así que yo creo que sabe hasta donde llega el nivel del agua, pero lo escribe de esa forma para dar que hablar.

  3. No sé, respeto mucho la trayectoria del Sr. Bob, pero yo creo que últimamente no está muy acertado en sus posts, como en éste sobre tipado estático y dinámico: http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html.

    En él dice cosas como «you don’t need static type checking if you have 100% unit test coverage.», pero luego te sale en el post que cito hablando de lo maravilloso que es eclipse y sus refactorizaciones automáticas, algo cuya corrección es imposible garantizar en un lenguaje dinámico.

    De todas formas, estoy de acuerdo contigo en que al final todos estamos más o menos de acuerdo. O al menos todos los que no somos demasiado fanáticos de nada en concreto.

  4. Yo creo que el señor tiene algo de razón, los lenguajes que uso comunmente son Java y Javascript(node), pero Node aun esta años luz de tener algo como JPA, entonces será necesario comenzar con los drivers al estilo JDBC, después será necesario una libreria parecida a hibernate, etc.
    Todo eso ya lo vivimos y vamos viendo como el patron se repite con Sailsjs y Waterline, si quiza mejorar el rendimiento, real time blablabla, pero supongo que existen otros problemas más solidos que afectan el mundo real que no estamos poniendo el foco que deberiamos, varios ejemplos los podemos encontrar en http://tangiblejs.com/ y bueno otro mas cuando vamos al baño y seguimos limpiandonos con papel arrugado (en la pelicula de el demoledor hacen alución a algo nuevo con que se limpian), pero en fin iterar es bueno y entre mejores herramientas tengamos, mas facil sera nuestro trabajo.

  5. Llevo 20 años desarrollando software, y nunca me he dejado llevar por las modas. He desarrollado en BASIC, en Clipper, C, C++, Turbo Pascal, Delphi, PHP y JavaScript. He ido cambiando según el entorno cambiaba, desde MS-DOS, Windows y ahora Web.

    Si tras leer, estudiar y probar una tecnología/lenguaje/librería, etc. no veo beneficios claros y palpables, no lo utilizo. Así de simple.

    Quizás soy demasiado pragmático y debería darle oportunidad a algunos lenguajes, o algunas tecnologías, puede ser, pero es que no tengo tiempo de probar tantas cosas, por lo que me ciño a lo estrictamente necesario para resolver el problema que se me plantea. Llamadme aburrido.

    A mi lo que verdaderamente me deja perplejo es que lenguajes o tecnologías que acaban de salir ya tengan miles de expertos sobre ellas, cuando yo llevo con algunos lenguajes varios años y aún hay cosas que voy descubriendo, técnicas que mejoran mi código.

    Creo que lo que el Dr. Bob quiere decir es que exprimamos al máximo lo que tenemos antes de embarcarnos en una búsqueda del lenguaje/framework/tecnología perfecta, porque simplemente no existe, hay demasiadas variantes como para que algo sea «perfecto». Cada problema puede tener diferentes soluciones, y cada una ser óptima desde algún punto de vista.

    Y estoy de acuerdo en que realmente el desarrollo de software aún está en pañales, si lo comparamos con otros ámbitos.

Comentarios cerrados.