- Los cambios de requisitos y la incertidumbre, el trabajo repetitivo y los parches que suelen considerarse propios del software también son comunes en la ingeniería tradicional, y ambos campos comparten más similitudes que diferencias
- La división entre ingeniería tradicional = Waterfall y software = Agile es excesivamente simplista. La fabricación física exige más diseño previo porque el costo de iterar es mayor, pero los túneles, la ingeniería civil y la electrónica también usan desarrollo incremental y adaptación en campo
- Al igual que proveedores que quiebran, cambios en equipos de manufactura o características imprevistas del suelo, la ingeniería tradicional también enfrenta problemas que trastocan los planes, así que es difícil decir que solo el software es impredecible
- La diferencia real está en la alta consistencia y rapidez de cambio del software, además de restricciones relativamente más flexibles. Los productos físicos deben lidiar con variaciones de materiales y desgaste, restricciones duras como resistencia y tamaño, y cambios difíciles de revertir
- Las correcciones rápidas facilitan la experimentación y la validación, pero también pueden presionar a rodear con código defectos físicos. Cada rama de la ingeniería puede aprender de las prácticas de diseño, validación y automatización de las demás
La lógica defensiva de que el software es especial
- Un yacimiento petrolero no es un globo lleno de petróleo sino una estructura rocosa porosa, por lo que puede ser difícil saber si una pérdida repentina de presión se debe a un vacío local o a una apertura hacia el mar
- Se inyectan cáscaras de avellana en pequeños huecos para llenarlos gradualmente, equilibrar la presión y probar si están dentro de la estructura
- El caso de que las petroleras en Noruega sean los mayores compradores de cáscaras de avellana muestra que la ingeniería tradicional también depende de materiales inesperados y de respuestas en terreno
- Al comparar software con ingeniería tradicional, a veces se menosprecia al software frente a la ingeniería por diferencias de licencia o rigor, pero al mismo tiempo se lo convierte en un campo especial que no puede entenderse dentro del marco general de la ingeniería
- La idea de que los requisitos cambian demasiado rápido como para aplicar planeación previa y métodos de ingeniería funciona como un mecanismo de defensa
- El movimiento NoEstimates busca eliminar la estimación misma porque, a diferencia de la ingeniería tradicional, estima que en software es demasiado difícil estimar
- Pero la mayoría de los problemas que en software se consideran dolorosos también existen en otras ramas de la ingeniería, y quienes han trabajado en ambos lados ven una cercanía esencial entre los dos tipos de trabajo
Cinco diferencias que suelen mencionarse
- Si se trata a toda la ingeniería tradicional como si fuera un solo campo, o se la identifica con la ingeniería civil, desaparecen las diferencias entre sus subdisciplinas
- Los puntos que suelen citarse como diferencias universales entre software e ingeniería tradicional son los siguientes
- La ingeniería tradicional encaja con Waterfall y el software con Agile
- La ingeniería tradicional es predecible, pero el software es difícil de predecir
- La ingeniería es sobre todo manufactura y el código es diseño, así que “el código es el diseño”
- La ingeniería tradicional es más rigurosa que la ingeniería de software
- El software se mueve mucho más rápido que la ingeniería tradicional
- En algunos casos hay diferencias reales, pero en la mayoría son afirmaciones equivocadas o les falta el contexto clave necesario para juzgarlas
La división simple entre Waterfall y Agile
- Según la narrativa más conocida, Winston Royce creó Waterfall en 1970 inspirado en procesos de construcción, y ese enfoque, vulnerable a los cambios de requisitos, fue reemplazado en 2001 por el Agile Manifesto
- En realidad, Waterfall nunca fue tan rígido ni tan universal como hoy se cree
- En las décadas de 1970 y 1980, los desarrolladores usaban desde planificación ad hoc hasta varios modelos incrementales como el Spiral Model y el V Model
- Agile se parece más al resultado natural de esa evolución que a una revolución abrupta
- Es cierto que la ingeniería tradicional dedica más tiempo al diseño previo y a pruebas separadas, pero eso surge menos de la rigidez de Waterfall que de la economía del costo de iterar
- Cuanto más tiempo y dinero cuesta iterar, más razonable es planear durante más tiempo una sola ejecución
- Si una tarjeta de circuito no funciona desde el inicio, puede haber que devolverla a la fábrica, con un costo adicional de miles de libras y dos semanas de calendario
- La frontera entre diseño e implementación tampoco es clara
- Un modelo a escala de un ingeniero civil o una maqueta de arcilla a tamaño real que un ingeniero automotriz hace para probar estética y aerodinámica pueden verse tanto como diseño como implementación
- En otras industrias también existen métodos parecidos a Agile
- El método austríaco de túneles depende del desarrollo iterativo y de la improvisación en campo
- Handbook of Industrial Engineering enfatiza la colaboración entre departamentos y la retroalimentación rápida del cliente
- La ingeniería civil también, una vez iniciada la obra, se orienta a la comunicación abierta y la adaptación para resolver problemas del sitio
La ingeniería tradicional también es difícil de predecir
- Si solo se mira el puente o el producto terminado, es fácil perder de vista la fricción, los sobrecostos y los retrasos del proceso
- Basta con levantar una pared una pulgada fuera de lugar o con que quiebre un proveedor clave para desestabilizar el plan
- En software parece que cada 1 o 2 años cambian los frameworks o lenguajes dominantes, pero la ingeniería tradicional también vive cambios en herramientas y entornos de producción
- Si una fundición de semiconductores introduce nuevo equipo de fabricación, también cambian los planes de diseño del chip
- No cambia tan rápido como una librería, pero eso no significa que no cambie
- También puede pasar que cambie la titularidad durante una obra, que un procedimiento validado deje de funcionar de forma permanente de repente, o que aparezcan nuevos hechos al final del desarrollo
- Si al empezar la cimentación de un puente se descubre que cierto suelo se congela de forma distinta a lo esperado y se licua en exceso durante un sismo, hay que reiniciar desde el diseño
- La idea de que solo el software es especialmente impredecible surge de no ver cómo es realmente el trabajo en otras ramas de la ingeniería
La afirmación de que “el código es el diseño”
- “El código es el diseño” fue una reacción contra la idea de que bastaría con crear un modelo perfecto en UML y luego generar automáticamente el código
- Nick Coghlan, desarrollador principal de CPython y exingeniero de integración de sistemas en Boeing, lo ve como una diferencia fundamental entre el software y su trabajo anterior
- Coordinaba múltiples equipos de sistemas independientes para que crearan interfaces compatibles, como en aeronaves, control de tráfico aéreo y arreglos de antenas
- Para un ingeniero de semiconductores, todo el proceso desde el primer esquema del CPU hasta el chip final salido de la fundición es diseño, y la manufactura puede ser una etapa relativamente simple de enviar el diseño y recibir el chip
- Si un chip terminado o un producto mecánico tiene defectos, hay que cambiar el diseño, así que diseño y fabricación no están separados
- En ingeniería mecánica, el “fettling” consiste en ajustar el diseño a pequeñas imperfecciones del proceso de fabricación
- La fabricación cambia el diseño, y el diseño cambiado vuelve a cambiar la fabricación, creando un ciclo
- Incluso el alcance del diseño en sí es ambiguo
- Un resumen de arquitectura, una especificación formal y un plano detallado son todos diseño, pero en niveles distintos
- En proyectos complejos como este plano de puente, existen detalles repetidos en múltiples capas
- La característica de gastar la mayor parte del tiempo y del costo en la construcción aplica a algunas áreas de la ingeniería civil centradas en puentes y edificios, pero no puede generalizarse como representación de toda la ingeniería tradicional
- La ingeniería civil también incluye muchas áreas necesarias para construir ciudades, así que no se limita solo a puentes y edificios
Malentendidos sobre el rigor
- La división entre una ingeniería tradicional que razona cuidadosamente desde primeros principios y un software que depende de copiar y pegar no refleja el trabajo real
- El rigor relativamente menor que parece tener el software no es solo un problema cultural, sino también una compensación racional derivada de las propiedades materiales que facilitan implementar y probar
- Muchas veces, la forma más fácil de verificar una suposición es implementarla directamente y ejecutarla
- Reunir información empírica rápidamente es, en sí mismo, una forma rigurosa de validación
- Tampoco es correcto asumir que los productos de ingeniería tradicional son más consistentes y sistemáticos que el software
- El software a veces incluso lleva ventaja en conservación de registros y validación integral
- En muchos casos, información clave de la ingeniería tradicional se guarda en archivos de Excel o en archivadores viejos y termina obsoleta o dañada
- También hay muchos ingenieros tradicionales que quisieran incorporar las pruebas automatizadas que en software se consideran normales
- Incluso en estructuras físicas se siguen usando parches cuando hace falta, como agregar un soporte
Diferencia real 1: consistencia
- El software se compone enteramente de lógica y no se desgasta como un resorte, así que es mucho más consistente que otros resultados de ingeniería
- Si una función de ordenamiento solo ordenara correctamente el 95% de las listas numéricas válidas, sería difícil aceptarlo como un comportamiento normal
- En los materiales y componentes físicos existen de forma inherente desviaciones respecto de los valores teóricos
- Las resistencias se ofrecen desde 1Ω hasta cientos de millones de Ω y usan bandas de color para indicar su valor teórico
- Las bandas verde, azul y roja significan 5,600Ω, pero si además hay una banda dorada de tolerancia, el valor real puede variar hasta 5%
- Entre 100 resistencias iguales, algunas pueden medir 5,320Ω y otras 5,880Ω, así que hay que medirlas individualmente
- Si además se considera el desgaste y los cambios de temperatura, la variación se vuelve aún más compleja
- Todos los materiales físicos tienen problemas similares, y hasta el fabricante de tornillos Fastenal advierte no usar tornillos de acero inoxidable en placas de aluminio
Diferencia real 2: velocidad de cambio
- El software puede modificarse mucho más rápido que otros sistemas de ingeniería
- En la ingeniería tradicional, hay que compartir la especificación, esperar la fabricación e instalación en una fábrica o taller, y luego semanas de pruebas
- Algunos cambios de ingeniería tienen un costo claramente visible, como quitar 5,000 dólares del presupuesto cada vez
- En código, tras un cambio se puede ejecutar toda la batería de pruebas en segundos
- Entre los campos no relacionados con software, la ingeniería química fue la que mostró una velocidad más cercana, pero aun así a un nivel donde incluso cambios por minuto son difíciles de imaginar
- Una razón por la que otras ramas de la ingeniería usan cada vez más software en herramientas de diseño y simulación es que permite prototipar ideas rápidamente antes de implementarlas
- La capacidad de cambiar rápido también tiene un lado negativo
- Si un problema en un dispositivo electrónico o mecánico no se resuelve por completo, la presión suele concentrarse en que un ingeniero de software lo compense con un rodeo en código
- Esa dependencia puede tener consecuencias fatales
- En los dos accidentes del Boeing 737 MAX de 2019 murieron más de 300 personas
- La investigación señaló como causa un bug en el sistema automático de control de vuelo MCAS
- Boeing añadió MCAS en lugar de corregir mediante diseño físico un problema de características aerodinámicas de la aeronave detectado tardíamente
Diferencia real 3: restricciones y cambios irreversibles
- Los productos de ingeniería tradicional tienen límites físicos que deben respetarse, como peso, resistencia, tolerancia o temperatura
- En el diseño de chips, incluso se puede negociar con otros equipos un margen de tiempo de fracciones de nanosegundo
- El software también tiene restricciones, como capacidad de memoria, respuesta de un sensor en 10 ciclos o límites de llamadas a una API
- Pero en software muchas restricciones son blandas: mientras más se exceden, peor se comporta el sistema, así que a veces es posible mover un poco el límite para avanzar más rápido o usar un algoritmo más simple
- En la ingeniería tradicional, en cambio, muchas restricciones son duras: si se exceden, el producto no funciona
- Si una caja es apenas un poco más ancha, ya no pasa por la puerta
- En un caso de un tornillo transportador que debía instalarse en una plataforma petrolera, el equipo resultó unas pulgadas más alto que la sala y no podía recortarse ni elevar el techo por los cuatro niveles de arriba
- La solución fue abrir un agujero en el techo para meter el equipo y poner una caja alrededor para que la gente del piso superior no tropezara
- Ese cambio quedó de forma permanente en la estructura y tuvo que seguir considerándose en todas las modificaciones posteriores
- Un ingeniero de software puede revertir un parche, pero un parche físico en ingeniería tradicional tiende a convertirse en una estructura permanente
Diferentes, pero no especiales
- El software tiene problemas propios de seguridad, pero la ingeniería civil tiene el clima y la ingeniería química las propiedades químicas; cada campo tiene desafíos particulares
- Todas las ramas de la ingeniería valoran el pensamiento abstracto previo, el trabajo ordenado y los parches adecuados, y enfrentan requisitos cambiantes e incógnitas desconocidas
- Cada disciplina está aislada de las demás, así que a un ingeniero de software le cuesta conocer la ingeniería mecánica tanto como a un ingeniero químico entender el trabajo real de otras ramas
- Precisamente porque el software no es especial, puede aprender formas de mejora de otras ingenierías, y la ingeniería tradicional también puede aprender del software en aspectos como registro, validación y automatización
- El texto posterior Lo que la ingeniería puede enseñarnos y lo que puede aprender de nosotros aborda lecciones concretas que ambas partes pueden intercambiar
1 comentarios
Opiniones en Lobste.rs
Estoy de acuerdo con buena parte del texto, pero es demasiado optimista sobre el rigor de la ingeniería de software. Incluso hoy, no es algo obvio que las pruebas automatizadas, especialmente pruebas sólidas en varias capas, formen parte del proceso de desarrollo, y a veces se considera al propio desarrollador como el único punto de control, o la organización trata los procesos como obstáculos y los elimina
La industria reinventa la rueda cada pocos años sin sistematizar las mejores prácticas comprobadas. Incluso lo que está estandarizado suele ser solo un vocabulario común laxo cuyo significado varía mucho entre empresas; ‘agile’ y ‘testing’ son ejemplos representativos. Muchos desarrolladores piensan en testing solo como pruebas unitarias, algunos incluyen también pruebas de componentes e integración, pero en algunas empresas despliegan a producción habiendo pasado solo por eso
Como escribí en un comentario anterior, en una organización sana la revisión de código debería ser uno de varios procesos responsables de la calidad, y no la única puerta que decide el despliegue a producción. Hay muchos equipos y empresas donde los procesos de aseguramiento de calidad posteriores al merge del código prácticamente han desaparecido
No se trata de diluir la responsabilidad, sino de incorporar la calidad al proceso desde antes de escribir código. Hacen falta sesiones de Three Amigos donde distintos perfiles discutan especificaciones y requisitos, desarrollo guiado por pruebas, análisis estático integrado al IDE y a cada punto de control, y especialistas en QA y automatización de pruebas separados de los desarrolladores
En la ingeniería civil, una sola persona no es al mismo tiempo el diseñador del puente, el constructor y el único responsable. Hay múltiples etapas, como cálculos y documentación, recálculos, aprobación gubernamental, auditorías e inspecciones durante la construcción, e incluso una casa unifamiliar pasa por planos, aprobaciones, permisos e inspecciones. Los desastres de ingeniería también suelen ser fallas del proceso completo, que no logró detenerlos en varias etapas
Si vamos a comparar el desarrollo de software con la ingeniería civil, también hay que reconocer que el nivel de proceso no es en absoluto el mismo. En el mejor de los casos, muchas veces se parece más a un desarrollador inmobiliario que construye la casa más barata posible mientras esquiva los requisitos legales
Por eso, fuera de áreas como el software de control de MRI, en el software general el punto de equilibrio entre el costo de probar y verificar y el efecto de hacerlo inevitablemente será distinto al de la ingeniería civil
Los tres textos son excelentes, así que recomiendo leerlos. También se puede ver el debate anterior
https://lobste.rs/s/fv8swh/crossover_project (presentación del proyecto)
https://lobste.rs/s/lmvroa/are_we_really_engineers (nuevo debate)
https://lobste.rs/s/8j8sdc/are_we_really_engineers (otro nuevo debate)
Esta charla de Glenn Vanderburg también es muy relevante
La mayor diferencia entre el desarrollo de software y la ingeniería tradicional es la fricción asociada al cambio. El software puede modificarse con un costo relativamente bajo y es flexible, lo que abre posibilidades completamente nuevas
La ingeniería tradicional también puede ampliar la posibilidad de hacer cambios de forma parecida al software, dentro de límites físicos y químicos, cuanto más simulaciones construya
La frase “si es una función de ordenamiento, no esperas que ordene una lista no patológica de números con solo un 95% de probabilidad” ahora también aplica de verdad al código generado por LLM. La mayor parte del tiempo funciona, pero no siempre
Me pregunto por qué ~hwayne desactivó su cuenta