- Una presentación que resume 40 principios prácticos aplicables al diseño de naves espaciales y a proyectos de ingeniería
- Destaca como principios clave el análisis basado en datos numéricos, el diseño iterativo y el diseño tolerante a fallas
- Incluye una advertencia realista: los cronogramas solo se mueven en una dirección y las estimaciones iniciales siempre están subestimadas
- Aplicable tal cual más allá de la ingeniería espacial, a software, sistemas y diseño de startups en general
- Una lista de verificación realista para prevenir errores que se repiten en el juicio ingenieril
Ley 1 — La ingeniería se demuestra con números
- "Engineering is done with numbers. Analysis without numbers is only an opinion."
- La ingeniería se hace con números; el análisis sin números no es más que una opinión
- La razón por la que quienes estudian ingeniería dedican tanto tiempo a aprender matemáticas
- El éxito ingenieril debe ser cuantificable
- "Mi sistema es más rápido" → ¿qué tanto más rápido?
- "Mi sistema es más barato" → ¿cuánto cuesta?
- "Mi sistema es más simple" → ¿cómo se mide la simplicidad?
Ley 2 — Diseño tolerante a fallas
- "To design a spacecraft right takes an infinite amount of effort. This is why it's a good idea to design them to operate when some things are wrong."
- Diseñar correctamente una nave espacial requiere un esfuerzo infinito, por eso conviene diseñarla para que funcione incluso cuando algunas cosas salgan mal
- No diseñar sistemas que exijan 100% de confiabilidad
- Casos de falla: Deepwater Horizon, Fukushima
- Ejemplo del método de verificación lógica triple (3 way logic checking) en sistemas de control de aeronaves
Ley 3 — Proceso de diseño iterativo
- "Design is an iterative process. The necessary number of iterations is one more than the number you have currently done. This is true at any point in time."
- El diseño es un proceso iterativo, y la cantidad de iteraciones necesarias siempre es una más que las que has hecho hasta ahora
- Un buen diseño nunca está realmente terminado
Ley 4 — Cómo lidiar con la decepción
- "Your best design efforts will inevitably wind up being useless in the final design. Learn to live with the disappointment."
- Tus mejores esfuerzos de diseño pueden terminar siendo inútiles en el diseño final; hay que aprender a vivir con esa decepción
- Ley de Bhargava: solo 1 de cada 10 proyectos de investigación llega a aplicarse en la práctica industrial
- El mayor éxito comercial no necesariamente es el mejor diseño técnico
- Ejemplo: Nokia N95 vs iPhone de primera generación
Ley 5 (Ley de Miller) — Tres puntos determinan una curva
- "Three points determine a curve."
- Tres puntos determinan una curva
- En un conjunto de datos, siempre se termina encontrando algún patrón
- Hay que verificar si ese patrón proviene del fenómeno real que se estudia y no del ruido de medición
- La academia y los estudiantes de posgrado tienden especialmente a ignorar esta regla
Ley 6 (Ley de Mar) — Cuidado con el sobreajuste de datos
- "Everything is linear if plotted log-log with a fat magic marker."
- Todo parece lineal en una gráfica log-log si la dibujas con un marcador grueso
- Ley de Bigg: "No te enamores de una herramienta matemática; la herramienta no te va a corresponder"
- Prohibido sobreajustar los datos (over-fit)
Ley 7 — Liderazgo y formación de equipos
- "At the start of any design effort, the person who most wants to be team leader is least likely to be capable of it."
- Al inicio de cualquier proyecto de diseño, quien más quiere ser líder del equipo suele ser quien menos probabilidades tiene de ser capaz de hacerlo
- La historieta Dilbert se basa en experiencias reales de empresas de ingeniería, solo un poco exageradas
- Parte del liderazgo es innato, pero una parte importante debe aprenderse
- Hay gerentes que no logran 'respetar lo básico (respect the basics)'
- Pregúntale a un ingeniero industrial sobre los MBA
Ley 8 — El punto óptimo está en el medio
- "In nature, the optimum is almost always in the middle somewhere. Distrust assertions that the optimum is at an extreme point."
- En la naturaleza, el punto óptimo casi siempre está en algún punto intermedio; hay que desconfiar de las afirmaciones que lo colocan en un extremo
- Ejemplo estándar: transferencia óptima de potencia (Optimal power transfer)
- Ejemplo práctico: resistencia óptima del sensor (optimal sensor resistance)
Ley 9 — La falta de información no es excusa
- "Not having all the information you need is never a satisfactory excuse for not starting the analysis."
- No tener toda la información necesaria nunca es una excusa satisfactoria para no empezar el análisis
- Hay que identificar qué valores hacen falta para poder hacer un análisis más completo
Ley 10 — Estimar y adivinar
- "When in doubt, estimate. In an emergency, guess. But be sure to go back and clean up the mess when the real numbers come along."
- Si tienes dudas, estima. En una emergencia, adivina. Pero asegúrate de volver y arreglar el desastre cuando lleguen los números reales
- Te entrenan para ser ingeniero, no adivino
- En esta profesión, pensar bien es más importante que pensar rápido
Ley 11 — Empezar de nuevo desde cero
- "Sometimes, the fastest way to get to the end is to throw everything out and start over."
- A veces, la manera más rápida de llegar al final es tirar todo y empezar de nuevo
- Aprender cuándo hay que hacer esto toma tiempo
- En muchas industrias hubo casos en los que debió hacerse y no se hizo
- Almaz, estación espacial soviética tripulada de reconocimiento: era un diseño técnico sobresaliente, pero tras su lanzamiento quedó obsoleta frente a satélites de reconocimiento con control por computadora
- Los primeros 'automóviles'
Ley 12 — No existe una única respuesta correcta
- "There is never a single right solution. There are always multiple wrong ones, though."
- Nunca existe una sola solución correcta, aunque siempre hay múltiples incorrectas
- Mantén la mente abierta
- La ingeniería no es una religión
- La apostasía técnica (Technical apostasy) está totalmente permitida
- Ejemplo: cálculo automático mecánico
- Fue el enfoque dominante en la Segunda Guerra Mundial
- El hardware digital no dominó este campo sino hasta la década de 1960
Ley 13 — Diseño basado en requisitos
- "Design is based on requirements. There's no justification for designing something one bit 'better' than the requirements dictate."
- El diseño se basa en requisitos; no hay justificación para diseñar algo ni un poco 'mejor' de lo que exigen los requisitos
- A los clientes no les gusta pagar por funciones que no necesitan
- Hay que encontrar el nivel de confiabilidad que requiere la aplicación y diseñar de acuerdo con ese nivel
- Suena fácil, pero ejecutarlo es difícil
Ley 14 (Ley de Edison) — 'Mejor' es enemigo de 'bueno'
- "Lo 'mejor' es enemigo de lo 'bueno'."
- "Mejor" es enemigo de "bueno"
- En realidad, es una cita de Voltaire
- Hay que reconocer cuándo un sistema ha llegado a un estado suficientemente bueno (good enough)
- Como la perfección exige recursos infinitos, un sistema siempre puede mejorarse más
- Ver la ley 13
Ley 15 (ley de Shea) — las interfaces son la clave
- "The ability to improve a design occurs primarily at the interfaces. This is also the prime location for screwing it up."
- La capacidad de mejorar un diseño ocurre principalmente en las interfaces; este también es el principal lugar donde puede echarse a perder
- Hay muchos ingenieros/técnicos que entienden realmente bien un solo sistema
- Son pocos los que entienden realmente bien varios sistemas distintos
- Ejemplo: en sistemas con interacciones complejas entre hardware y software, los problemas suelen aparecer en las interfaces
Ley 16 — no confiar ciegamente en análisis anteriores
- "The previous people who did a similar analysis did not have a direct pipeline to the wisdom of the ages. There is therefore no reason to believe their analysis over yours. There is especially no reason to present their analysis as yours."
- Las personas anteriores que hicieron un análisis similar no tenían una línea directa hacia la sabiduría de los tiempos; por lo tanto, no hay razón para creer en su análisis por encima del tuyo, y mucho menos para presentar su análisis como si fuera tuyo
Ley 17 — la precisión de las publicaciones
- "The fact that an analysis appears in print has no relationship to the likelihood of its being correct."
- El hecho de que un análisis aparezca impreso no guarda relación con la probabilidad de que sea correcto
- Opiniones famosas de los años 70:
- "1200 baud probablemente será la velocidad máxima que podrán alcanzar los módems telefónicos"
- Conocido por la frase "Coding is dead"
- La trellis coded modulation llevó esta velocidad hasta 50 kbps en los años 90
Ley 18 — la doble cara de la experiencia pasada
- "Past experience is excellent for providing a reality check. Too much reality can doom an otherwise worthwhile design, though."
- La experiencia pasada es excelente para hacer una comprobación de realidad, pero demasiada realidad puede condenar un diseño que de otro modo valdría la pena
Ley 19 — la importancia de la humildad
- "The odds are greatly against you being immensely smarter than everyone else in the field. If your analysis says your terminal velocity is twice the speed of light, you may have invented warp drive, but the chances are a lot better that you've screwed up."
- Es muy poco probable que seas muchísimo más inteligente que todos los demás en el campo; si tu análisis dice que tu velocidad terminal es el doble de la velocidad de la luz, tal vez inventaste el warp drive, pero es mucho más probable que te hayas equivocado
Ley 20 — la importancia de la presentación
- "A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately."
- Un mal diseño con una buena presentación está condenado tarde o temprano; un buen diseño con una mala presentación está condenado de inmediato
- Ejemplo: Avro C102 — el segundo avión comercial a reacción del mundo (por 13 días de diferencia)
- Fue cancelado para apoyar el desarrollo del Avro Arrow
Ley 21 — la esencia de la educación
- "Half of everything you hear in a classroom is crap. Education is figuring out which half is which."
- La mitad de todo lo que oyes en un salón de clases es basura; la educación consiste en averiguar cuál mitad es cuál
- No es que los profesores intenten desperdiciar deliberadamente el 50% del tiempo
- Se trata de adivinar qué habilidades serán necesarias en campos que cambian y evolucionan rápidamente
- Ejemplo: computación cuántica
- Puede ser conocimiento esencial para trabajar como ingeniero durante los próximos 20 años, o puede seguir siendo solo de interés académico hasta la década de 2030
Ley 22 — la importancia de documentar
- "When in doubt, document. (Documentation requirements will reach a maximum shortly after the termination of a program.)"
- Ante la duda, documenta. Los requisitos de documentación alcanzarán su máximo poco después de que termine un programa
- Si no puedes resolver un problema, no ocultes tu ignorancia
- Documenta la causa del problema
- Puede que otra persona encuentre cómo resolverlo
Ley 23 — el carácter ficticio del cronograma
- "The schedule you develop will seem like a complete work of fiction up until the time your customer fires you for not meeting it."
- El cronograma que desarrolles parecerá una obra completa de ficción hasta que tu cliente te despida por no cumplirlo
Ley 24 — estructura de desglose del trabajo
- "It's called a 'Work Breakdown Structure' because the Work remaining will grow until you have a Breakdown, unless you enforce some Structure on it."
- Se llama "Work Breakdown Structure" porque el trabajo restante seguirá creciendo hasta que tengas un colapso (Breakdown), a menos que le impongas algo de estructura (Structure)
Ley 25 (ley de Bowden) — análisis después de una falla en pruebas
- "Following a testing failure, it's always possible to refine the analysis to show that you had negative margins all along."
- Después de una falla en pruebas, siempre es posible refinar el análisis para mostrar que tuviste márgenes negativos desde el principio
- Ejemplos: informes de accidentes de la Junta Canadiense de Investigación de Seguridad en el Transporte y de la Administración Federal de Aviación (FAA)
- Algunas fallas ocurren por falta de imaginación (paráfrasis de Frank Borman)
- A un ingeniero se le perdona cometer errores, pero no se le perdona ocultarlos
Ley 26 (ley de Montemerlo) — no hacer tonterías
- "Don't do nuthin' dumb."
- En la práctica de la ingeniería, es una regla sorprendentemente difícil de seguir
- No olvides lo básico
- Aclara tus prioridades
Ley 27 (ley de Varsi) — los cronogramas van en un solo sentido
- "Schedules only move in one direction."
- Los cronogramas solo se mueven en una dirección
- Deja margen para problemas y dificultades
- Fallas en pruebas
- Más adelante, emergencias familiares
- Puede que otra persona entregue tarde el producto necesario aunque no sea culpa tuya
- Siempre deja holgura en el cronograma para ti y para tu equipo
Ley 28 (ley de Ranger) — no existe el lanzamiento gratis
- "There ain't no such thing as a free launch."
- No existe tal cosa como un lanzamiento gratis
Ley 29 (ley de gestión de programas de von Tiesenhausen) — estimación de costos y tiempo
- "Para obtener una estimación precisa de los requisitos finales del programa, multiplica las estimaciones iniciales de tiempo por pi, y recorre el punto decimal de las estimaciones de costo un lugar hacia la derecha."
- Para obtener una estimación precisa de los requisitos finales del programa, multiplica las estimaciones iniciales de tiempo por π y mueve el punto decimal de las estimaciones de costo un lugar a la derecha
Ley 30 (ley de diseño de ingeniería de von Tiesenhausen) — el impacto del concepto artístico
- "If you want to have a maximum effect on the design of a new engineering system, learn to draw. Engineers always wind up designing the vehicle to look like the initial artist's concept."
- Si quieres tener el máximo impacto en el diseño de un nuevo sistema de ingeniería, aprende a dibujar; los ingenieros siempre terminan diseñando el vehículo para que se vea como el concepto artístico inicial
Ley 31 (ley de desarrollo evolutivo de Mo) — los límites fundamentales de la tecnología
- "You can't get to the moon by climbing successively taller trees."
- No puedes llegar a la luna subiéndote a árboles cada vez más altos
- Es útil entender los límites fundamentales de una tecnología o enfoque
Ley 32 (ley de las demos de Atkin) — la ley de Murphy
- "When the hardware is working perfectly, the really important visitors don't show up."
- Cuando el hardware funciona perfectamente, los visitantes realmente importantes no aparecen
Ley 33 (ley de planificación de programas de Patton) — la importancia de ejecutar
- "A good plan violently executed now is better than a perfect plan next week."
- Un buen plan ejecutado con decisión ahora es mejor que un plan perfecto la próxima semana
- Error en la industria: esperar la tecnología 'perfecta'
- Mientras esperas, la competencia se apodera del mercado
Ley 34 (ley de planificación de tareas de Roosevelt) — ejecución realista
- "Do what you can, where you are, with what you have."
- Haz lo que puedas, donde estés, con lo que tienes
- A menos que seas escritor de ciencia ficción, no tiene sentido diseñar para tecnología que no existe
Ley 35 (ley de diseño de de Saint-Exupéry) — diseño perfecto
- "A designer knows that he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away."
- Un diseñador sabe que ha alcanzado la perfección no cuando ya no queda nada por agregar, sino cuando ya no queda nada por quitar
Ley 36 — elegancia, eficiencia y efectividad
- "Any run-of-the-mill engineer can design something which is elegant. A good engineer designs systems to be efficient. A great engineer designs them to be effective."
- Cualquier ingeniero del montón puede diseñar algo elegante; un buen ingeniero diseña sistemas para que sean eficientes; un gran ingeniero los diseña para que sean efectivos
- Diseño elegante (Elegant design): sistema estándar de agua potable urbana
- Diseño eficiente (Efficient design): sistema de agua de Nueva York
- Diseño efectivo (Effective design): sistemas de irrigación de civilizaciones indígenas de Norteamérica y Sudamérica (algunos siguen funcionando desde hace más de 1000 años)
Ley 37 (ley de Henshaw) — líneas claras de responsabilidad
- "One key to success in a mission is establishing clear lines of blame."
- Una de las claves del éxito en una misión es establecer líneas claras de responsabilidad
- Debes hacerte responsable de tus acciones y decisiones
- No confíes en ingenieros (o en cualquier otra persona) que se nieguen a asumir responsabilidad
Ley 38 — las capacidades impulsan los requisitos
- "Capabilities drive requirements, regardless of what the systems engineering textbooks say."
- Las capacidades impulsan los requisitos, sin importar lo que digan los libros de texto de ingeniería de sistemas
- La clave es reconocer qué nuevas capacidades se están desarrollando:
- Década de 1950: transistor
- Década de 1960: circuitos integrados
- Década de 1970: microprocesador
- Década de 1980: computadora personal
- Década de 1990: internet
- Década de 2000: computación inalámbrica/móvil
Ley 39 — no desarrollar un nuevo vehículo de lanzamiento
- Tres claves para mantener barato y en plazo un nuevo programa espacial tripulado:
- No crear un nuevo vehículo de lanzamiento
- No crear un nuevo vehículo de lanzamiento
- Pase lo que pase, no decidir desarrollar un nuevo vehículo de lanzamiento
- Hay que evitar la tentación de creer que un producto completamente nuevo siempre será mejor que la evolución de uno existente
Ley 40 — el espacio no perdona
- "Space is a completely unforgiving environment. If you screw up the engineering, somebody dies (and there's no partial credit because most of the analysis was right...)"
- El espacio es un entorno completamente implacable; si arruinas la ingeniería, alguien muere (y no hay puntos parciales porque la mayor parte del análisis haya sido correcta...)
- Grandes desastres de control de ingeniería:
- Fukushima, Chernóbil
- De Havilland Comet (la razón por la que las ventanas de los aviones comerciales de pasajeros tienen esquinas redondeadas)
- Eastern Airline Flight 401 (el piloto automático guio un avión comercial hacia los Everglades)
- Therac-25 (equipo canadiense de radioterapia)
- Paráfrasis de Richard Feynman: "No se puede engañar a la naturaleza (Nature cannot be fooled)"
1 comentarios
Comentarios de Hacker News
La afirmación de que en los años 90 se llegó a 50 kilobaudios con Trellis coded modulation es algo inexacta
La capacidad de Shannon calculada a partir del ancho de banda y las características de SNR de la línea telefónica estaba alrededor de 30 kb/s, y los módems V.34 se acercaron a ese límite al alcanzar 33.6 kb/s
Pero desde los 80, la red telefónica ya se había digitalizado, salvo por la “última milla”
Si el módem del ISP emitía audio digital directamente, teóricamente se podía llegar hasta 64 kb/s, aunque en la práctica eran unos 53 kb/s por las restricciones de potencia de la FCC
En ese tiempo yo trabajaba en un equipo de investigación sobre modulación de módems, y a los ingenieros acostumbrados a pensar en analógico les tomó bastante tiempo darse cuenta de las posibilidades de un canal digital
Después pasaron a los cable módems y regresaron otra vez al mundo analógico
Si el tramo hasta la casa seguía siendo analógico, ¿no seguía estando limitado por Shannon-Nyquist?
Si entre el módem del ISP y el módem de casa hubiera un cable de cobre sin filtro, ¿no sería posible simplemente transmitir varios Mbps por UART?
Me gustaría que esa parte se explicara con más claridad
Fue gracias a varias técnicas de codificación y compresión, incluyendo Trellis coding, y todavía hoy se puede comprar un módem 56k de US Robotics
La Law 20 describe con precisión la realidad actual de las startups
Como dice eso de que “un buen diseño que se encuentra con una mala presentación fracasa de inmediato”, la capacidad de comunicarlo es absolutamente crucial
Explicarlo bien también es prueba de que lo entienden
Me recuerda a la frase de que “si no puedes explicárselo a un niño de 5 años, tú tampoco lo entiendes”
Sobre la idea de que “el mayor éxito comercial no es el mejor diseño técnico”
La comparación entre el Nokia N95 y el iPhone de primera generación no me parece adecuada. Yo propondría en cambio la Canyon’s Law of Design Optimization: la métrica que quiere el cliente y la que optimiza el desarrollador no son la misma, y no hay que intentar convencer al cliente de que está equivocado
El iPhone de primera generación tenía una forma y una interfaz excelentes, pero le faltaban funciones. 3G, GPS, apps de terceros y cámara eran débiles
No fue sino hasta el iPhone 3G que consiguió un verdadero éxito comercial
Falta la última diapositiva
La frase clave es: “Ignora todos los consejos anteriores y haz lo correcto”
Encontrar el equilibrio entre consejos que se contradicen es la verdadera ingeniería, y es el objetivo más difícil tanto en lo técnico como en lo social
Dice que el análisis previo no es una verdad absoluta y que hay que confiar en el propio juicio
Este PDF parece nuevo, pero Akin’s Laws of Spacecraft Design existe desde 2003
También se puede comprobar en este enlace del archivo web
Con solo ver la primera ley ya se entiende por qué es difícil llamar verdadera ingeniería a la “ingeniería” de software
Llevo mucho tiempo citando la ley de von Tiesenhausen
Eso de que “el ingeniero al final diseña según el concepto del artista inicial” lo he sentido igual en proyectos web
Muchas veces la persona que hizo el documento inicial, o la que dejó las notas en la reunión, termina definiendo la dirección del producto
Aunque se llame “ágil”, en la práctica sigue siendo dependiente de la trayectoria
Tomé en MIT la clase capstone de diseño de naves espaciales en 2003, pero nunca vi esta lista
En ese entonces el proyecto estaba centrado en satélites, y da la impresión de que la filosofía de Akin estaba incorporada de manera implícita
La ingeniería espacial tenía una cultura de diseño conservadora, así que el avance era lento, y antes de Elon Musk los cambios todavía eran más lentos
En particular me impactó la frase de que “el espacio es un entorno implacable y un fracaso de ingeniería equivale a pérdida de vidas”
Además coincidía con la época del desastre del Columbia en 2003
Probablemente la Law 31 (entiende los límites de la tecnología existente) activó la Law 11 (tíralo todo y empieza de nuevo), y la Law 16 (no confíes ciegamente en análisis anteriores) lo respaldó
Yo prefiero sistemas que no requieran mantenimiento y que sean fáciles de reemplazar
Las tecnologías de software eventualmente desaparecen, así que la estructura debería ser reemplazable en cualquier momento, como el hardware
Me llegó especialmente el consejo de “evita la tentación de creer que un producto completamente nuevo siempre es mejor que una evolución del producto existente”