Pablo Santos Luaces

Comentarios al artículo “Programmers: Stop Calling Yourselves Ingeneers” (publicado en The Atlantic en noviembre de 2015 – https://www.theatlantic.com/technology/archive…).

Resumen ejecutivo

Lo que dice el artículo	Contestación
El artículo incide en que en Silicon Valley se contrata “de todo” y se le llama “engineer”	Es cierto que con ese nombre encuentras a gente salida de “bootcamps”, pero también a montones de ingenieros salidos de prestigiosas universidades de todo el mundo (MIT, Standford, universidades españolas y europeas, indias, todo el mundo)
Habla de “Ingenieros Civiles” una y otra vez como el sumun de la ingeniería haciendo cosas serias como puentes y obras públicas	Es el “proyectos vs productos” de siempre. Sí, pero también son ingenieros los que hacen coches, aviones, neveras o ascensores. Y esos no son obra pública y no dejan de ser ingenieros. Trabajan en “productos” que es más comparable con el trabajo de casi todo el software que usamos a diario
Habla de procesos rígidos de ingeniería y critica los procesos ágiles por ser “flexibles”	Esta es una de los tópicos que pensaba que estaban ya desterrados: compararnos con “la arquitectura”.   Las casas NO se hacen mejor que el software, y los puentes tampoco. La materia prima es diferente.   Y, por supuesto, puentes y edificios se diseñan y calculan con software, que parece en el artículo que sale de la privilegiada mente del ingeniero directamente.   Una vez liberados del complejo, en software, hemos ido a hacer procesos muy controlados (devops, por ejemplo) pero sacando partido de que el software es flexible.   En vez de fustigarnos con “es que no somos capaces de hacer funcionar un waterfall”, aprovechamos la flexibilidad.   Es más, veremos cómo los procesos (punteros, eso sí) de software se aplicarán en otras industrias con éxito (ejemplo manido: Tesla/SpaceX, gente originariamente de software revolucionando otras industrias).
Traditional engineers are regulated, certified, and subject to apprenticeship and continuing education. Engineering claims an explicit responsibility to public safety and reliability, even if it doesn’t always deliver.	Por supuesto que necesitamos tener ingenieros regulados. Para proyectos públicos, claro. Para poder ejercer la responsabilidad que la sociedad exige y en la que invierte con la formación de miles de ingenieros.   Pero, del mismo modo que no hay que ser ingeniero regulado para construir el próximo modelo de coche utilitario o de súper deportivo, ni de avión, tampoco para construir un producto software, aunque lo usen millones de personas. Otra cosa es que el mercado exija pruebas de calidad o sellos.   En mi opinión el autor mezcla, a propósito, conceptos para confundir.   Un “ingeniero civil regulado” es necesario para “obra pública” => proyectos públicos.   Lo mismo estaríamos encantados de que ocurriera para proyectos públicos en software.   Ahora bien, él hace referencia constante a los productos de Silicon Valley que, insisto, son *productos* y no proyectos.   Habla de que los ingenieros de software están bajo “capas de management” => lo mismo que cualquier ingeniero en el diseño de cualquier otro producto.
Incide en el tópico de que “el software falla” y hasta resalta el escándalo de las emisiones de Volkswagen	Echar la culpa de lo de las emisiones a que el software “no es ingeniería” me parece fuera de lugar. Es una estafa, un delito, lo que quiera, pero nada tiene que ver con eso. O el mismo planteamiento se puede aplicar a todos los problemas en obras civiles. Un ejemplo cercano y fresco: el famoso túnel ferroviario entre León y Asturias, ¿será que la de caminos tampoco es una ingeniería? http://m.ileon.com/noticia/actualidad/072006/el-agua-en-los-tuneles-del-ave-a-asturias-ya-cuesta-260-millones-y-sin-solucion-definitiva

La razón principal por la que comento este artículo es la siguiente: incide en el tópico de que “programar” no es ingeniería. E insiste en lo “formal” de otros procesos.

Primero hay que distinguir entre diseño y fabricación. Cuando la mayoría de las veces se habla de lo formal y repetible de los procesos de “otras” ingenierías se hace referencia a la fase de construcción. Fabricar un coche, construir un puente. No se hace referencia a la fase de diseño.

En software la construcción es *automática* y más repetible y perfecta que en ninguna otra ingeniería. La conversión de “plano” en “producto” es instantánea y sin margen de error.

Tenemos los planos más formales y libres de subjetividad: el código. El código son los planos del software. “The code is the design” que explicó Jack Reeves en sus famosos artículos hace más de una década (http://www.developerdotstar.com/mag/articles/reeves_design_main.html).

Con esta perspectiva, la auto-flagelación de “no tenemos planos” y “somos unos aficionados”, cambia.

Que la conversión de plano en producto sea instantánea y sin errores es lo que habilita los procesos iterativos e incrementales. Aprovechamos esta característica “física” y sacamos partido. Por eso cuando se compara la construcción de casas con el software se cae en tópicos ya caposos y que más allá del chiste ignoran esta diferencia fundamental.

 

En todas las demás ingenierías la fase de construcción es cara, lenta y con posibilidad de errores. Todo su trabajo previo se basa en que no haya que pasar por esa fase dos veces. En software no es así.

 

Por supuesto que hay muchísimo software (sobre todo proyectos) con una calidad que deja mucho que desear. Pero es que en software (como en cualquier otra disciplina), conviven proyectos en los que se aplican técnicas actuales con otros en los que el reloj se paró hace treinta años.

Un proceso “actual” de software se puede describir como:

• Se programa una nueva característica o corrección de defecto (y viene detrás de un *diseño* de la misma cuando procede => que sería un “diseño del diseño” si lo comparamos con otras disciplinas).
• Se hace revisión de ese código (code review).
• Se somete ese cambio a un proceso de pruebas automático capaz de localizar fallos y regresiones. Si se detecta un error, se rechaza el cambio.
• Se integra el cambio en la línea principal de desarrollo y se somete a un juego mucho más extenso de pruebas automáticas, pruebas exploratorias manuales (basadas en aprovechar la inteligencia y conocimiento de producto del humano), rendimiento, estrés.
• Si todo lo anterior es satisfactorio, se pone en producción la nueva versión.

Las empresas punteras repiten este ciclo decenas de veces al día. Así es como trabajan Google, Amazon, Facebook, Etsy, Netflix y millares de empresas de mucho menor tamaño.

Hay muchos proyectos en los que todo esto se ignora. Algunos de ellos desarrollan para el sector público, y acabamos viendo a los afectados (medicina, justicia) manifestándose y preguntándose por qué el software que usan para el trabajo no funciona tan bien como el que usan en su vida diaria.

 

Usar la excusa de que “se contratan personal sin formación regulada” en muchas empresas de software (algo que ni critico ni me parece relevante en esta conversación, es su decisión), para concluir que la ingeniería de software no es ingeniería, sería como decir que como la mayoría de los ingenieros civiles no están en cálculo de estructuras sino dirigiendo proyectos y haciendo trabajo de gestión (de hecho la oficina técnica está peor remunerada) tampoco “son ingeniería”.