Pablo Santos Luaces. Vicedecano

Hace dos días me encontré con un retweet del famosísimo gurú Martin Fowler de un artículo que decía “¿podemos considerarnos realmente ingenieros de software?”. Otra vez el mismo rollo, pero esta vez con una aproximación bien diferente: preguntando a ingenieros que han estado en ambos lados, en ingeniería tradicional y en software.
El artículo son en realidad 3 partes y te recomiendo que si tienes un rato lo leas:
https://www.hillelwayne.com/post/crossover-project/are-we-really-engineers

Pero, por si no te da tiempo, voy a hacer un brevísimo resumen.
No hay grandes diferencias con el resto
Muy resumido: los que suelen decir que “la de software no es una ingeniería porque…” asumen como ciertas sus impresiones sobre lo que se hace en otras disciplinas, pero no se basan en hechos reales.
El autor ha hecho un estudio hablando con unos cuantos ingenieros mecánicos, civiles, químicos, que se han pasado al software y por tanto comprenden bien varias áreas. Y la respuesta de todos ellos ha sido “no es tan diferente” y “por supuesto es una ingeniería”.
Habla de que se asume que la ingeniería tradicional se basa mucho en las matemáticas. Explica que es en matemáticas continuas, mientras que el software lo hace en matemática discreta, y que por tanto intentar tachar al software como “otra cosa”, no tiene sentido. Un ingeniero industrial y uno electrónico también se centran en diferentes áreas y nadie lo ve como un problema.
Habla de los ingenieros que necesitan tener licencia para ejercer (el viejo tema). Y explica que en la mayoría de ingenierías, solo el “ingeniero principal” lo requiere para firmar el proyecto, no el resto del equipo, y eso no los hace menos ingenieros. Dice que no se puede mezclar la política/regulación con si es o no ingeniería. Recuerda que solo hace 100 años no había ni un ingeniero con licencia en Estados Unidos, hasta que para reducir desviaciones de costes se comenzó a pedir.

Desmonta waterfall
Habla de cómo se asume que la ingeniería tradicional usa un ciclo estricto en cascada y explica que no es verdad, que la aproximación ágil se ha extendido a todas las profesiones, y que el waterfall demonizado que ahora conocemos tampoco fue nunca real, que siempre se hablaba de tener feedback y trabajar en iteraciones.

¿Qué podemos aprender y enseñar?
Habla del control de versiones como la mayor aportación de la ingeniería de software que se sitúa lejos de lo que en otras disciplinas manejan (aunque haya opciones, no tan buenas).
Que podemos aprender a ser más profesionales con el trabajo, a tomar más responsabilidad.
Que en ninguna otra disciplina ha encontrado conferencias de practitioners como hay en software, algo que permite ser más abiertos y que fluya más el conocimiento.

Algunas frases impactantes
• Version control is the single most innovative, most revolutionary, most paradigm-shifting tool that is uniquely ours. Some other fields have proto-VCS, things with a fraction of the power and versatility.
• “I’m gonna respond in a slightly different way. Not every software developer is a software engineer, just like not every single person who works in construction is an engineer. An engineer is a very specific set of skills. […] Software [engineering] is skill plus understanding, all the processes and life cycle and the consequences and all the things that you should be aware of [and] avoid. -Dawn (Mechanical & Chemical)”
• We see Agile-like innovations in every industry. Many tunnels today are built with Austrian Tunneling, which relies on iterative development and lots of room for improvisation. The Handbook of Industrial Engineering emphasises cross-collaboration and rapid client feedback.
• “Software is More Unpredictable”. This misconception comes from us seeing the results of the engineering process, not the process itself. We don’t see the friction, the overruns, the delays that happen because someone built the wall one inch to the left, or when a critical supplier goes out of business. To assume that software is uniquely unpredictable is a special kind of arrogance.
• We software engineers take the existence of nonacademic, noncorporate conferences for granted. But we’re unique here. In most fields of engineering, there are only two kinds of conferences: academic conferences and vendor trade shows.
• Plenty would kill to get the same kind of automated testing we treat as a given.
• Software is far more consistent than any other kind of engineering.
• “it was all design”, from the first schematics of the CPU to the final chips rolling out of the foundry. All of their time was spent on design, just like software. Construction was the easy part: just hand the design over to a foundry and get back completed chips.

Más lecturas actuales y clásicas sobre software engineering
Me encontré una definición muy buena de programación vs ingeniería en el libro “Software Engineering at Google: Lessons Learned from Programming Over Time”, de marzo de 2020, en el que dice que ingeniería es “integrar programación en el tiempo”, integral como en matemáticas, se refiere. Es un libro muy potente.
Y finalmente el clásico, pero siempre relevante “The code is the design” de Jack W. Reeves: https://www.developerdotstar.com/mag/articles/reeves_design_main.html que explica de forma interesantísima como no hay plano en ninguna ingeniería más exacto que el código.