Un ingeniero de software generalmente piensa que el buen software es el resultado de la implementación de patrones probados, de mantenerse dentro de las reglas, de usar la disciplina y de seguir procesos formales y mejores prácticas.
Un programador sabe que todo eso es una mierda.
Escribir código es más parecido a componer música, o a escribir libros, producir películas y definitivamente a las artes gráficas que a construir puentes. De hecho, es más difícil porque tiene que hacer algo más que parecer o sonar bien. Todo el mundo sabe que la buena música, la literatura y el arte no tienen que ver con el cumplimiento de las normas, sino con las reglas que se rompen y las nuevas ideas que se exploran. ¿Alguien cree que los artículos más populares de las listas de éxitos musicales y de los bestsellers se sitúan ahí por el cumplimiento de alguna norma o regla? Esa lista sería muy diferente y poco popular porque la sociedad avanza hacia cosas nuevas o hacia cosas viejas con un nuevo giro, pero nunca se asentará.
Los mejores programas son sencillos, hacen naturalmente lo que uno quiere, funcionan de forma fiable y pueden usarse de forma suficientemente intuitiva como para no ser molestos. Lo que se deja fuera es generalmente más importante que lo que se añade: no queremos que sea configurable, queremos que se configure solo o que no necesite configuración. Probablemente ni siquiera nos demos cuenta de la mayoría de los mejores programas que se utilizan hoy en día a nuestro alrededor porque simplemente funcionan y no tenemos que pensar ni preocuparnos por ellos. Cuando el software nos molesta, no nos importa lo bien que los «ingenieros de software» siguieron sus reglas y procesos, simplemente estamos molestos y el software apesta porque se trata de personas y de resolver un problema, no de las herramientas y la tecnología – coge la herramienta apropiada una vez que entiendas el problema – y prueba diferentes herramientas a medida que lo entiendes más – no al revés. Cuando el software nos asombra, siguen sin importarnos las reglas y los procesos, sólo que nos asombra y nos inspira a hacer cosas similares. Así que parece que sólo los ingenieros se preocupan por las reglas y los procesos.
Encuentro que las personas que se inclinan hacia una mentalidad de ingeniería tienden a centrarse en la tecnología y el código y si el proceso se siguió correctamente (¿TDD? ¿MVC?) y lo bien que se mide a las reglas en su mayoría arbitrarias para la estructura y el estilo sin mucha consideración por el problema real que se resuelve o lo que el usuario realmente necesita. El mejor software proviene de un enfoque equilibrado en el usuario, el problema y la tecnología, y en ese orden de prioridad. Los mejores resultados suelen provenir de pequeños y sencillos cambios en los tres, pero si sólo nos centramos en la «ingeniería» sólo vemos un aspecto de la situación.
El problema es que la creatividad se ahoga cuando nos vemos obligados a seguir unas reglas o a ceñirnos a un proceso detallado. Algunas directrices y procesos generales están bien para mantener a la dirección contenta de que están obteniendo el valor que desean, pero esta industria se mueve muy rápido y las verdaderas innovaciones del futuro no saldrán de las ‘mejores prácticas’. Los ingenieros tienden hacia esas ‘mejores prácticas’ mientras que los programadores buscan innovar y encontrar una manera de hacer más con menos trabajo y puede que no siga el proceso o llegue según lo previsto pero funcionará.
Por ejemplo: ¿Quizás 200 líneas de código Node.js resolverían este problema más fácil y mejor que 10.000 líneas de código Java EE? Tal vez un pequeño cambio en la forma en que el usuario percibe el problema podría reducir la complejidad de la solución?
En el punto en el que el usuario, el problema y la tecnología (programador) convergen, surge una interesante realidad y oportunidades que sólo un programador puede ver. Me parece que los ingenieros tienden a no verlas porque ya han decidido cómo se va a resolver el problema antes de entenderlo. El control de cambios se invocará a medida que el problema se revele en su mundo.
He sido programador desde los 14 años (autodidacta y luego universitario) y seguí toda la trayectoria profesional hasta diseñador, arquitecto y me di cuenta de que ahora sólo dibujaba diagramas, escribía documentos y era una pérdida de tiempo y no muy satisfactoria. Ahora tengo 48 años y estoy codificando de nuevo y me encanta porque puedo hacer que las cosas sucedan más rápido y mejor de lo que nunca pude antes y hacer que funcione bien para el usuario, no sólo hablar de ello en descripciones de alto nivel y abstracciones.
Mientras que algunas personas sienten que el término ingeniero conlleva una cierta credibilidad por encima de un humilde ‘programador’, yo prefiero el término programador o desarrollador de software porque la ingeniería es una disciplina por naturaleza y mientras que una viga de acero y el hormigón obedecerán las reglas si seguimos el proceso para instalarlos, las personas, los ordenadores y el software no funcionan de esa manera – imagina que el acero y el hormigón tienen rasgos de comportamiento y propiedades que se pueden cambiar sobre la marcha.
Para mí, la programación y el desarrollo de software es más bien un arte o un talento que hay que practicar y, aunque requiere cierta disciplina, se trata mucho más de crear algo nuevo -y, con suerte, realmente genial- que entretenga o aporte algún valor real a alguien.