- Slide que organiza 40 princípios práticos aplicáveis ao projeto de espaçonaves e a projetos de engenharia
- Destaca como princípios centrais a análise baseada em números, o projeto iterativo e o projeto tolerante a falhas
- Inclui o alerta realista de que cronogramas só andam em uma direção e de que estimativas iniciais são sempre subestimadas
- Vai além da engenharia espacial e pode ser aplicado diretamente a software, sistemas e design de startups em geral
- Checklist prático para evitar erros recorrentes de julgamento em engenharia
Lei 1 — Engenharia comprovada por números
- "Engineering is done with numbers. Analysis without numbers is only an opinion."
- Engenharia é feita com números; análise sem números é apenas opinião
- O motivo de estudantes de engenharia investirem tanto tempo aprendendo matemática
- O sucesso em engenharia precisa ser quantificável
- "Meu sistema é mais rápido" → quanto mais rápido?
- "Meu sistema é mais barato" → qual é o custo?
- "Meu sistema é mais simples" → como a simplicidade é medida?
Lei 2 — Projeto tolerante a falhas
- "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."
- Projetar uma espaçonave da forma correta exige um esforço infinito; por isso, é uma boa ideia projetá-la para operar mesmo quando algumas coisas estiverem erradas
- Não projete sistemas que exijam 100% de confiabilidade
- Casos de falha: Deep Water Horizon, Fukushima
- Exemplo do método de verificação lógica tripla (3 way logic checking) em sistemas de controle de aeronaves
Lei 3 — Processo de projeto 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."
- Projeto é um processo iterativo, e o número de iterações necessárias é sempre um a mais do que o número já realizado até agora
- Um bom projeto nunca está realmente concluído
Lei 4 — Lidar com a decepção
- "Your best design efforts will inevitably wind up being useless in the final design. Learn to live with the disappointment."
- Seus melhores esforços de projeto inevitavelmente podem acabar sendo inúteis no projeto final; aprenda a conviver com essa decepção
- Lei de Bhargava: apenas 1 em cada 10 projetos de pesquisa é aplicado na prática industrial
- O maior sucesso comercial não é necessariamente o melhor projeto técnico
- Exemplo: Nokia N95 vs iPhone de 1ª geração
Lei 5 (Lei de Miller) — Três pontos determinam uma curva
- "Three points determine a curve."
- Três pontos determinam uma curva
- Em um conjunto de dados, sempre acabamos encontrando um padrão
- É preciso verificar se esse padrão vem de um fenômeno real em estudo ou apenas de ruído de medição
- Academia e pós-graduandos tendem especialmente a ignorar essa regra
Lei 6 (Lei de Mar) — Cuidado com overfitting de dados
- "Everything is linear if plotted log-log with a fat magic marker."
- Tudo parece linear em um gráfico log-log quando desenhado com um marcador grosso
- Lei de Bigg: "não se apaixone por uma ferramenta matemática; ela não vai retribuir esse amor"
- Não faça overfitting de dados
Lei 7 — Liderança e formação de equipe
- "At the start of any design effort, the person who most wants to be team leader is least likely to be capable of it."
- No início de qualquer esforço de projeto, a pessoa que mais quer ser líder de equipe é a que tem menor chance de ser capaz disso
- A tira Dilbert se baseia em experiências reais de empresas de engenharia, com um pouco de exagero
- Parte da liderança é inata, mas uma parcela considerável precisa ser aprendida
- Há casos em que gestores não conseguem 'respeitar o básico (respect the basics)'
- Pergunte a um engenheiro industrial sobre um MBA
Lei 8 — O ponto ótimo fica no meio
- "In nature, the optimum is almost always in the middle somewhere. Distrust assertions that the optimum is at an extreme point."
- Na natureza, o ótimo quase sempre está em algum ponto intermediário; desconfie de afirmações de que o ótimo está em um extremo
- Exemplo padrão: transferência ótima de potência (Optimal power transfer)
- Exemplo prático: resistência ótima do sensor (optimal sensor resistance)
Lei 9 — Falta de informação não é desculpa
- "Not having all the information you need is never a satisfactory excuse for not starting the analysis."
- Não ter todas as informações de que você precisa nunca é uma desculpa satisfatória para não começar a análise
- É preciso identificar quais valores são necessários para uma análise mais completa
Lei 10 — Estimar e chutar
- "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."
- Na dúvida, estime. Em uma emergência, chute. Mas volte e arrume a bagunça quando os números reais aparecerem
- Você é treinado para ser engenheiro, não vidente
- Nesta profissão, pensar bem é mais importante do que pensar rápido
Lei 11 — Recomeçar do zero
- "Sometimes, the fastest way to get to the end is to throw everything out and start over."
- Às vezes, a forma mais rápida de chegar ao fim é jogar tudo fora e começar de novo
- Leva tempo aprender quando isso deve ser feito
- Há muitos casos em que indústrias deveriam ter feito isso, mas não fizeram
- Estação espacial soviética tripulada de reconhecimento Almaz: era um excelente projeto técnico, mas ficou obsoleta após o lançamento por causa de satélites de reconhecimento com controle por computador
- Os primeiros 'automóveis'
Lei 12 — Não existe uma única resposta certa
- "There is never a single right solution. There are always multiple wrong ones, though."
- Nunca existe uma única solução correta, embora sempre existam várias erradas
- Mantenha a mente aberta
- Engenharia não é religião
- Apostasia técnica (Technical apostasy) é totalmente permitida
- Exemplo: cálculo automático mecânico
- Foi a abordagem dominante na Segunda Guerra Mundial
- O hardware digital só dominou essa área na década de 1960
Lei 13 — Projeto baseado em requisitos
- "Design is based on requirements. There's no justification for designing something one bit 'better' than the requirements dictate."
- Projeto se baseia em requisitos; não há justificativa para projetar algo nem um bit 'melhor' do que os requisitos determinam
- Clientes não gostam de pagar por recursos de que não precisam
- É preciso encontrar o nível de confiabilidade exigido pela aplicação e projetar de acordo com ele
- É fácil falar, mas difícil executar
Lei 14 (Lei de Edison) — 'Melhor' é inimigo de 'bom'
- "Melhor" é inimigo de "bom".
- “Melhor” é inimigo de “bom”
- Na verdade, é uma citação de Voltaire
- É preciso reconhecer quando um sistema atingiu um estado bom o suficiente (
good enough)
- Como a perfeição exige recursos infinitos, sempre é possível melhorar ainda mais um sistema
- Veja a Lei 13
Lei 15 (Lei de Shea) — interfaces são o núcleo
- "The ability to improve a design occurs primarily at the interfaces. This is also the prime location for screwing it up."
- A capacidade de melhorar um projeto ocorre principalmente nas interfaces, que também são o principal lugar para estragá-lo
- Há muitos engenheiros/técnicos que entendem muito bem um único sistema
- É raro encontrar alguém que entenda muito bem vários sistemas diferentes
- Ex.: sistemas com interações complexas entre hardware e software costumam apresentar problemas nas interfaces
Lei 16 — não confie cegamente em análises 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."
- As pessoas que fizeram análises semelhantes antes não tinham uma linha direta com a sabedoria dos séculos; portanto, não há motivo para acreditar mais na análise delas do que na sua, e muito menos para apresentar a análise delas como se fosse sua
Lei 17 — a precisão das publicações
- "The fact that an analysis appears in print has no relationship to the likelihood of its being correct."
- O fato de uma análise aparecer impressa não tem relação com a probabilidade de ela estar correta
- Opinião famosa dos anos 1970:
- "1200 baud provavelmente será a velocidade máxima que um modem telefônico poderá atingir"
- Ficou conhecida pela frase "Coding is dead"
- A trellis coded modulation elevou essa velocidade para 50kbps até os anos 1990
Lei 18 — a dualidade da experiência passada
- "Past experience is excellent for providing a reality check. Too much reality can doom an otherwise worthwhile design, though."
- A experiência passada é excelente para fornecer um teste de realidade, mas realidade demais pode condenar um projeto que, de outra forma, teria valor
Lei 19 — a importância da humildade
- "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."
- As chances de você ser muito mais inteligente do que todo o resto da área são extremamente pequenas; se a sua análise diz que sua velocidade terminal é o dobro da velocidade da luz, você pode ter inventado o warp drive, mas é muito mais provável que tenha cometido um erro
Lei 20 — a importância da apresentação
- "A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately."
- Um projeto ruim com uma boa apresentação está condenado mais cedo ou mais tarde; um projeto bom com uma apresentação ruim está condenado imediatamente
- Exemplo: Avro C102 — o segundo jato comercial de passageiros do mundo (por uma diferença de 13 dias)
- Foi cancelado para apoiar o desenvolvimento do Avro Arrow
Lei 21 — a essência da educação
- "Half of everything you hear in a classroom is crap. Education is figuring out which half is which."
- Metade de tudo o que você ouve em sala de aula é bobagem; educação é descobrir qual metade é qual
- Não é que os professores tentem desperdiçar deliberadamente 50% do tempo
- Trata-se de tentar adivinhar quais habilidades serão necessárias em áreas que mudam e evoluem rapidamente
- Exemplo: computação quântica
- Pode ser conhecimento essencial para trabalhar como engenheiro nos próximos 20 anos ou continuar sendo apenas um interesse acadêmico até os anos 2030
Lei 22 — a importância da documentação
- "When in doubt, document. (Documentation requirements will reach a maximum shortly after the termination of a program.)"
- Na dúvida, documente. (As exigências de documentação atingirão o máximo logo após o encerramento de um programa.)
- Se não conseguir resolver um problema, não esconda sua ignorância
- Documente a causa do problema
- Outra pessoa pode encontrar uma forma de resolvê-lo
Lei 23 — a natureza fictícia dos cronogramas
- "The schedule you develop will seem like a complete work of fiction up until the time your customer fires you for not meeting it."
- O cronograma que você desenvolver parecerá uma obra completa de ficção até o momento em que o cliente demitir você por não cumpri-lo
Lei 24 — estrutura analítica do trabalho
- "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."
- Chama-se Work Breakdown Structure (estrutura analítica do trabalho) porque o trabalho restante continuará crescendo até você ter um colapso (
breakdown), a menos que imponha alguma estrutura a ele
Lei 25 (Lei de Bowden) — análise após falha em testes
- "Following a testing failure, it's always possible to refine the analysis to show that you had negative margins all along."
- Depois de uma falha em testes, sempre é possível refinar a análise para mostrar que as margens já eram negativas desde o início
- Exemplo: relatórios de acidentes do Conselho de Segurança na Investigação de Acidentes de Transporte do Canadá e da Federal Aviation Administration (FAA)
- Algumas falhas acontecem por falta de imaginação (paráfrase de Frank Borman)
- Engenheiros podem ser perdoados por cometer erros, mas não por escondê-los
Lei 26 (Lei de Montemerlo) — não faça besteira
- "Don't do nuthin' dumb."
- Uma regra surpreendentemente difícil de seguir na prática da engenharia
- Não se esqueça do básico
- Deixe suas prioridades claras para si mesmo
Lei 27 (Lei de Varsi) — cronogramas só andam em uma direção
- "Schedules only move in one direction."
- Cronogramas só se movem em uma direção
- Reserve uma folga para problemas e dificuldades
- Falha em testes
- Mais tarde, uma emergência familiar
- Alguém pode entregar tarde o produto necessário sem que a culpa seja sua
- Sempre deixe margem no cronograma para você e para a equipe
Lei 28 (Lei de Ranger) — não existe lançamento grátis
- "There ain't no such thing as a free launch."
- Não existe lançamento grátis
Lei 29 (Lei de gerenciamento de programas de von Tiesenhausen) — estimativa de custo e tempo
- "Para obter uma estimativa precisa dos requisitos finais do programa, multiplique as estimativas iniciais de tempo por pi e desloque a vírgula decimal das estimativas de custo uma casa para a direita."
- Para obter uma estimativa precisa dos requisitos finais do programa, multiplique as estimativas iniciais de tempo por π e desloque a vírgula decimal das estimativas de custo uma casa para a direita
Lei 30 (Lei de projeto de engenharia de von Tiesenhausen) — O impacto do conceito do artista
- "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."
- Se você quiser ter o máximo de influência no projeto de um novo sistema de engenharia, aprenda a desenhar; os engenheiros sempre acabam projetando o veículo para que ele se pareça com o conceito artístico inicial
Lei 31 (Lei do desenvolvimento evolutivo de Mo) — Limitações fundamentais da tecnologia
- "You can't get to the moon by climbing successively taller trees."
- Você não chega à Lua subindo árvores cada vez mais altas
- É útil entender os limites fundamentais da tecnologia/abordagem
Lei 32 (Lei da demonstração de Atkin) — Lei de Murphy
- "When the hardware is working perfectly, the really important visitors don't show up."
- Quando o hardware está funcionando perfeitamente, os visitantes realmente importantes não aparecem
Lei 33 (Lei do planejamento de programas de Patton) — A importância da execução
- "A good plan violently executed now is better than a perfect plan next week."
- Um bom plano executado com vigor agora é melhor do que um plano perfeito na semana que vem
- Erro na indústria: esperar pela tecnologia 'perfeita'
- Enquanto espera, o concorrente domina o mercado
Lei 34 (Lei do planejamento de tarefas de Roosevelt) — Execução realista
- "Do what you can, where you are, with what you have."
- Faça o que puder, onde você está, com o que você tem
- A menos que você seja um escritor de ficção científica, não faz sentido projetar para uma tecnologia que não existe
Lei 35 (Lei de projeto de de Saint-Exupéry) — Projeto perfeito
- "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."
- Um projetista sabe que alcançou a perfeição não quando não há mais nada a acrescentar, mas quando não há mais nada a retirar
Lei 36 — Elegância, eficiência e eficácia
- "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."
- Qualquer engenheiro mediano pode projetar algo elegante; um bom engenheiro projeta sistemas para serem eficientes; um grande engenheiro os projeta para serem eficazes
- Projeto elegante (Elegant design): sistema padrão de abastecimento urbano de água
- Projeto eficiente (Efficient design): sistema de abastecimento de água de Nova York
- Projeto eficaz (Effective design): sistemas de irrigação das civilizações indígenas da América do Norte e da América do Sul (alguns em funcionamento há mais de 1000 anos)
Lei 37 (Lei de Henshaw) — Linhas claras de responsabilidade
- "One key to success in a mission is establishing clear lines of blame."
- Uma das chaves para o sucesso em uma missão é estabelecer linhas claras de responsabilidade
- É preciso assumir responsabilidade por suas ações e decisões
- Não confie em engenheiros (ou em qualquer outra pessoa) que se recusem a assumir responsabilidade
Lei 38 — Capacidades determinam requisitos
- "Capabilities drive requirements, regardless of what the systems engineering textbooks say."
- As capacidades determinam os requisitos, independentemente do que digam os livros de engenharia de sistemas
- O ponto principal é reconhecer quais novas capacidades estão sendo desenvolvidas:
- Anos 1950: transistor
- Anos 1960: circuito integrado
- Anos 1970: microprocessador
- Anos 1980: computador doméstico
- Anos 1990: internet
- Anos 2000: computação sem fio/móvel
Lei 39 — Proibido desenvolver um novo veículo lançador
- Três pontos-chave para manter um novo programa espacial tripulado barato e dentro do cronograma:
- Nenhum novo veículo lançador
- Nenhum novo veículo lançador
- Não decidir desenvolver um novo veículo lançador, aconteça o que acontecer
- É preciso evitar a tentação de acreditar que um produto totalmente novo será sempre melhor do que a evolução de um produto existente
Lei 40 — O espaço não perdoa
- "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...)"
- O espaço é um ambiente completamente implacável; se você estragar a engenharia, alguém morre (e não há crédito parcial porque a maior parte da análise estava certa...)
- Grandes desastres de controle de engenharia:
- Fukushima, Chernobyl
- De Havilland Comet (o motivo de aviões comerciais terem janelas com cantos arredondados)
- Eastern Airline Flight 401 (o piloto automático guiou um avião comercial para os Everglades)
- Therac-25 (equipamento canadense de radioterapia)
- Paráfrase de Richard Feynman: "A natureza não pode ser enganada (Nature cannot be fooled)"
1 comentários
Comentários no Hacker News
A afirmação de que nos anos 1990 chegaram a 50 kilobaud com Trellis coded modulation é um pouco diferente da realidade
A capacidade de Shannon calculada a partir da largura de banda e das características de SNR da linha telefônica ficava na faixa de 30 kb/s, e os modems V.34 chegaram perto desse limite, alcançando 33,6 kb/s
Mas, desde os anos 1980, a rede telefônica já havia sido digitalizada, exceto pela “última milha”
Se o modem do ISP emitisse áudio digital diretamente, teoricamente seria possível chegar a 64 kb/s, mas na prática o limite era cerca de 53 kb/s por causa das restrições de potência da FCC
Na época eu trabalhava em uma equipe de pesquisa de modulação para modems, e os engenheiros acostumados ao pensamento analógico demoraram bastante para perceber o potencial de um canal digital
Depois disso, eles migraram para modems a cabo e voltaram novamente ao mundo analógico
Se o trecho até a casa continua sendo analógico, isso não continua preso ao limite de Shannon-Nyquist?
Se entre o modem do ISP e o modem doméstico houvesse um fio de cobre sem filtro, não seria possível simplesmente transmitir vários Mbps via UART?
Gostaria que essa parte fosse explicada com mais clareza
Isso foi possível graças a várias técnicas de codificação e compressão, incluindo Trellis coding, e ainda hoje é possível comprar um modem 56k da US Robotics
A Law 20 descreve com precisão a realidade das startups de hoje
Como diz a frase “um bom design encontra uma apresentação ruim e fracassa imediatamente”, a importância da capacidade de expressão é absoluta
Explicar bem também é prova de que se entendeu o assunto
Isso lembra a frase: “se você não consegue explicar para uma criança de 5 anos, então você mesmo não entendeu”
Sobre a frase “o maior sucesso comercial não é necessariamente o melhor projeto técnico”
A comparação entre o Nokia N95 e o iPhone de primeira geração não é adequada. Em vez disso, eu proponho a Lei de Otimização de Design de Canyon — os indicadores que o cliente quer e os que o desenvolvedor otimiza são diferentes, e você não deve tentar convencer o cliente de que ele está errado
O iPhone de 1ª geração tinha forma e interface excelentes, mas faltavam recursos. 3G, GPS, apps de terceiros e câmera, tudo era fraco
Só com o iPhone 3G ele alcançou um verdadeiro sucesso comercial
O slide final está faltando
A frase “Ignore todos os conselhos acima e faça a coisa certa” é a essência
Em meio a conselhos contraditórios, encontrar equilíbrio é a verdadeira engenharia, e é o objetivo mais difícil tanto tecnicamente quanto socialmente
O conteúdo é que “a análise anterior não é verdade absoluta, e é preciso confiar no próprio julgamento”
Este PDF parece novo, mas Akin’s Laws of Spacecraft Design existe desde 2003
Isso também pode ser confirmado no link do Web Archive
Só pela primeira lei já dá para ver por que é difícil chamar “engenharia” de software de engenharia de verdade
Há muito tempo eu cito a lei de von Tiesenhausen
Ela diz que “no fim, os engenheiros projetam de acordo com o conceito do artista inicial”, e senti exatamente isso também em projetos web
Muitas vezes, a pessoa que escreveu o documento inicial, ou quem deixou as anotações na reunião, acaba determinando a direção do produto.
Mesmo quando se chama de ‘ágil’, na prática tudo continua sendo dependente da trajetória
Em 2003, no MIT, cursei uma disciplina final de projeto de espaçonaves, mas nunca vi essa lista
Na época, o projeto era centrado em satélites, e parece que a filosofia de Akin estava presente de forma implícita
A engenharia espacial tinha uma cultura de projeto conservadora muito forte, então o ritmo de progresso era lento, e antes de Elon Musk as mudanças eram ainda mais lentas
Em especial, a frase “o espaço é um ambiente implacável, e falha de engenharia significa perda de vidas” me marcou muito
Isso também coincide com a época do desastre do Columbia em 2003
Provavelmente a Law 31 (entenda os limites da tecnologia existente) acionou a Law 11 (jogue tudo fora e recomece), e a Law 16 (não confie cegamente em análises anteriores) deu sustentação a isso
Eu prefiro sistemas que não exigem manutenção e são fáceis de substituir
Como tecnologias de software acabam desaparecendo, a estrutura deveria ser sempre substituível, como no hardware
O conselho “evite a tentação de acreditar que um produto completamente novo é sempre melhor do que uma evolução do produto existente” me tocou especialmente