- Mudanças de requisitos e incerteza, trabalho repetitivo e soluções provisórias, vistos como características exclusivas do software, também são comuns na engenharia tradicional; as duas áreas têm mais em comum do que diferenças
- A distinção de que a engenharia tradicional usa Waterfall e software usa Agile é simplista demais. A fabricação física tem custos de iteração altos, por isso exige mais projeto prévio, mas túneis, obras civis e eletrônica também usam desenvolvimento incremental e adaptação em campo
- Como a engenharia tradicional também enfrenta problemas que derrubam planos — fornecedores que fecham, mudanças em equipamentos de fabricação, características inesperadas do solo — é difícil dizer que só o software é especialmente imprevisível
- A diferença real está na alta consistência e na rapidez de mudança do software, além de restrições relativamente flexíveis. Produtos físicos precisam lidar com variação e desgaste de materiais, restrições rígidas como resistência e tamanho, e mudanças difíceis de reverter
- Correções rápidas facilitam experimentos e validação, mas também podem criar pressão para contornar em código defeitos físicos. Cada área da engenharia pode aprender com os métodos de projeto, verificação e automação das outras
A lógica de defesa de que software é especial
- Um reservatório de petróleo não é um balão cheio de óleo, mas uma estrutura de rocha porosa; por isso é difícil saber se uma queda súbita de pressão vem de um vazio local ou de uma abertura para o mar
- Injetam-se cascas de avelã em pequenos vazios para preenchê-los aos poucos, equilibrar a pressão e testar se estão dentro da estrutura
- O exemplo de que, na Noruega, empresas de petróleo são as maiores compradoras de cascas de avelã mostra que a engenharia tradicional também depende de materiais inesperados e respostas em campo
- Ao comparar software e engenharia tradicional, por um lado o software é avaliado abaixo da engenharia por diferenças de licenciamento ou rigor; por outro, também é transformado em uma área especial que não pode ser entendida dentro do arcabouço geral da engenharia
- O argumento de que os requisitos mudam de forma excepcionalmente rápida, portanto planejamento prévio e métodos de engenharia não precisam ser aplicados, funciona como um mecanismo de defesa
- O movimento NoEstimates tenta eliminar a própria estimativa, alegando que estimar software é difícil, ao contrário da engenharia tradicional
- Mas a maioria dos problemas considerados dolorosos em software também existe em outras áreas da engenharia, e engenheiros que passaram pelos dois lados veem a essência dos trabalhos como próxima
Cinco diferenças frequentemente citadas
- Tratar toda a engenharia tradicional como uma única área, ou igualá-la à engenharia civil, apaga as diferenças entre suas subáreas
- Os pontos abaixo costumam ser citados como diferenças universais entre software e engenharia tradicional
- A engenharia tradicional é adequada a Waterfall; software, a Agile
- A engenharia tradicional é previsível, mas software é difícil de prever
- Engenharia é principalmente manufatura, e código é projeto; portanto, “código é projeto”
- A engenharia tradicional é mais rigorosa que a engenharia de software
- Software se move muito mais rápido que a engenharia tradicional
- Em alguns casos há diferenças reais, mas a maioria dessas afirmações está errada ou carece do contexto essencial para julgamento
A distinção simplista entre Waterfall e Agile
- Segundo a narrativa mais conhecida, Winston Royce criou o Waterfall em 1970 inspirado no processo de construção, e esse método, frágil diante de mudanças de requisitos, foi substituído em 2001 pelo Manifesto Ágil
- Na prática, o Waterfall não era tão rígido nem tão universal quanto se imagina hoje
- Desenvolvedores das décadas de 1970 e 1980 usavam planejamento ad hoc e vários modelos incrementais, como o Spiral Model e o V Model
- Agile se parece mais com uma consequência natural das correntes da época do que com uma revolução abrupta
- É verdade que a engenharia tradicional gasta mais tempo com projeto prévio e testes separados, mas isso decorre mais da economia do custo de iteração do que da rigidez do Waterfall
- Quanto mais tempo e dinheiro uma iteração custa, mais racional é planejar por mais tempo antes de executar uma tarefa
- Se uma placa de circuito não funcionar de primeira, pode ser preciso mandá-la de volta à fábrica, acrescentando milhares de libras e duas semanas ao cronograma
- A fronteira entre projeto e implementação também não é clara
- Modelos em escala de engenheiros civis e modelos físicos em argila, feitos por engenheiros automotivos para testar estética e aerodinâmica, podem ser vistos tanto como projeto quanto como implementação
- Outros setores também têm métodos semelhantes ao Agile
- O Novo Método Austríaco de Túneis depende de desenvolvimento iterativo e respostas improvisadas em campo
- O Handbook of Industrial Engineering enfatiza colaboração entre departamentos e feedback rápido de clientes
- A engenharia civil também passa a priorizar comunicação aberta e adaptação para lidar com problemas de campo quando a construção começa
A engenharia tradicional também é difícil de prever
- Ao olhar apenas para uma ponte ou produto concluído, é fácil deixar passar o atrito, os estouros de custo e os atrasos que surgiram no processo
- Um muro construído 1 polegada fora do lugar, ou o fechamento de um fornecedor essencial, já pode desestabilizar o plano
- Software pode dar a impressão de que o framework ou a linguagem dominante muda a cada 1 ou 2 anos, mas a engenharia tradicional também passa por mudanças de ferramentas e ambientes de produção
- Quando uma foundry de semicondutores adota novos equipamentos de fabricação, o plano de projeto de chips também muda
- Mesmo que não seja tão rápido quanto bibliotecas, isso não significa ausência de mudança
- Também ocorrem casos em que a soberania territorial muda durante uma obra, um procedimento comprovado passa subitamente a falhar de forma permanente, ou um fato novo é descoberto no fim do desenvolvimento
- Se, depois de iniciar a fundação de uma ponte, descobrir-se que um determinado solo congela de modo diferente do esperado e liquefaz excessivamente durante terremotos, é preciso recomeçar a partir do projeto
- A ideia de que só software é especialmente imprevisível vem da falta de contato com o processo real de trabalho de outras áreas da engenharia
A afirmação de que “código é projeto”
- “Código é projeto” surgiu como reação à ideia de criar um modelo perfeito em UML e então gerar o código automaticamente
- Nick Coghlan, desenvolvedor principal do CPython e ex-engenheiro de integração de sistemas na Boeing, vê isso como uma diferença fundamental entre software e seu trabalho anterior
- Ele coordenava várias equipes de sistemas independentes, como aeronaves, controle de tráfego aéreo e arranjos de antenas, para que criassem interfaces compatíveis
- Para um engenheiro de semicondutores, todo o percurso, do primeiro esquemático de uma CPU ao chip final saído da foundry, é projeto; a fabricação pode ser uma etapa relativamente simples de entregar o projeto e receber o chip
- Se houver defeitos em um chip ou produto mecânico concluído, o projeto precisa ser alterado, portanto projeto e fabricação não são separados
- Na engenharia mecânica, “fettling” é o trabalho de ajustar o projeto às pequenas imperfeições do processo de fabricação
- Surge um ciclo em que a fabricação muda o projeto, e o projeto alterado muda novamente a fabricação
- O próprio escopo do projeto é indefinido
- Visões gerais de arquitetura, especificações formais e desenhos detalhados são todos níveis diferentes de projeto
- Em projetos complexos, como plantas de ponte, há detalhes recorrentes em várias camadas
- A característica de gastar mais tempo e dinheiro na construção se aplica a parte da engenharia civil centrada em pontes e edifícios, e não pode ser generalizada como a imagem representativa de toda a engenharia tradicional
- A engenharia civil também inclui diversas áreas necessárias à construção de cidades, portanto não se limita a pontes e edifícios
Equívocos sobre rigor
- A distinção de que a engenharia tradicional raciocina cuidadosamente a partir de primeiros princípios, enquanto software depende de copiar e colar, não reflete o trabalho real
- O rigor aparentemente menor do software pode não ser apenas uma questão cultural, mas uma troca racional decorrente das propriedades materiais que tornam implementação e testes fáceis
- Muitas vezes, a forma mais simples de verificar uma suposição é implementá-la diretamente e executá-la
- Coletar informações empíricas rapidamente também é, por si só, uma forma rigorosa de validação
- A premissa de que produtos da engenharia tradicional são mais consistentes e sistemáticos que software também não é correta
- Software às vezes está à frente em preservação de registros e validação abrangente
- Há muitos casos em que informações essenciais da engenharia tradicional ficam armazenadas em arquivos Excel ou em velhos arquivos físicos, envelhecendo ou se deteriorando
- Muitos engenheiros da engenharia tradicional gostariam de adotar testes automatizados, que em software são vistos como naturais
- Mesmo em estruturas físicas, soluções provisórias, como adicionar um suporte quando necessário, continuam sendo usadas
Diferença real 1: consistência
- Software é composto inteiramente de lógica e não se desgasta como uma mola, portanto é muito mais consistente do que outros resultados da engenharia
- Se uma função de ordenação ordenasse apenas 95% de uma lista de números que não fossem entradas anômalas, seria difícil aceitar isso como comportamento normal
- Materiais e componentes físicos têm, por padrão, variações em relação aos valores teóricos
- Resistores são oferecidos de 1Ω a centenas de milhões de Ω, e as faixas coloridas indicam o valor teórico da resistência
- Faixas verde, azul e vermelha significam 5.600Ω, mas, se houver uma faixa dourada de tolerância, o valor real pode variar até 5%
- Entre 100 resistores iguais, alguns podem ter 5.320Ω e outros 5.880Ω, exigindo medição individual
- Considerando também desgaste e mudanças de temperatura, as variações ficam ainda mais complexas
- Todos os materiais físicos têm problemas parecidos, e a fabricante de parafusos Fastenal também alerta para não usar parafusos de aço inoxidável em chapas de alumínio
Diferença real 2: velocidade de mudança
- Software pode ser alterado muito mais rapidamente que outros sistemas de engenharia
- Na engenharia tradicional, depois de compartilhar uma especificação, é preciso esperar a fabricação e a instalação na fábrica ou oficina mecânica, além de semanas de testes
- Algumas mudanças de engenharia têm custos explícitos, como US$ 5.000 saindo do orçamento a cada alteração
- Depois de mudar o código, é possível executar toda a suíte de testes em segundos
- Entre as áreas que não são software, a engenharia química foi a que chegou mais perto dessa velocidade, mas até uma transição em escala de 1 minuto é difícil de imaginar
- Outros campos da engenharia usam cada vez mais software em ferramentas de projeto e simulação justamente porque isso permite prototipar ideias rapidamente antes da implementação
- A capacidade de mudança rápida também tem um lado negativo
- Quando um problema em dispositivos eletrônicos ou mecânicos não é totalmente resolvido, a pressão se concentra nos engenheiros de software para compensá-lo com uma solução alternativa em código
- Essa dependência pode levar a consequências fatais
- Em 2019, duas quedas do Boeing 737 MAX mataram mais de 300 pessoas
- As investigações apontaram como causa um bug no MCAS, o sistema automático de controle de voo
- Em vez de corrigir no projeto físico um problema nas características aerodinâmicas da aeronave descoberto tardiamente, a Boeing acrescentou o MCAS
Diferença real 3: restrições e mudanças irreversíveis
- Produtos da engenharia tradicional têm limites físicos que precisam ser respeitados, como peso, resistência mecânica, resistência elétrica e temperatura
- No projeto de chips, até margens de tempo equivalentes a frações de nanossegundo podem ser negociadas com outras equipes
- Software também tem restrições, como capacidade de memória, resposta de 10 ciclos de um sensor e limites de chamadas de API
- Porém, em software, muitas restrições são soft constraints, em que o estado piora quanto mais se ultrapassa o limite; por isso, a fronteira pode ser ajustada um pouco em favor da velocidade de desenvolvimento ou de um algoritmo mais simples
- Na engenharia tradicional, muitas restrições são hard constraints: se forem ultrapassadas, o produto não funciona
- Se uma caixa for apenas um pouco larga demais, ela não passa pela porta
- Em um caso de um transportador helicoidal que seria instalado em uma instalação de perfuração de petróleo, o equipamento era alguns centímetros mais alto que a sala; não era possível reduzi-lo nem elevar o teto por causa dos quatro andares acima
- Fizeram um buraco no teto para inserir o equipamento e instalaram uma caixa ao redor do buraco para que as pessoas no andar de cima não tropeçassem
- Essa alteração permaneceu permanentemente na estrutura da instalação e precisou continuar sendo considerada em todas as mudanças posteriores
- Engenheiros de software podem reverter soluções provisórias, mas soluções provisórias físicas na engenharia tradicional tendem a se tornar estruturas permanentes
Diferente, mas não especial
- Software tem seus próprios problemas de segurança, mas cada área tem desafios distintos, como clima na engenharia civil e propriedades químicas na engenharia química
- Todas as áreas da engenharia valorizam pensamento abstrato prévio, trabalho organizado e soluções provisórias adequadas, e enfrentam requisitos em mudança e incógnitas desconhecidas
- Como cada área fica isolada das outras, engenheiros de software sabem pouco de engenharia mecânica, assim como engenheiros químicos têm dificuldade de conhecer o trabalho real de outras engenharias
- Como software não é especial, podemos aprender formas de melhorar com outras áreas da engenharia; e a engenharia tradicional também pode aprender com software em temas como registros, validação e automação
- O texto seguinte, O que a engenharia pode nos ensinar e o que ela pode aprender conosco, trata de lições concretas que os dois lados podem trocar
1 comentários
Comentários do Lobste.rs
Concordo com boa parte do texto, mas ele é otimista demais quanto ao rigor da engenharia de software. Mesmo hoje, não é algo dado que testes automatizados — especialmente testes robustos em várias camadas — façam parte do processo de desenvolvimento; muitas vezes o próprio desenvolvedor é visto como o único ponto de verificação, ou a organização trata processos como obstáculos e os elimina.
O setor reinventa a roda a cada poucos anos sem sistematizar boas práticas comprovadas. Mesmo o que foi padronizado geralmente não passa de um vocabulário comum frouxo, cujo significado varia muito de empresa para empresa; “ágil” e “teste” são exemplos típicos. Muitos desenvolvedores pensam em testes apenas como testes unitários, alguns incluem testes de componentes e de integração, mas em certas empresas o software passa só por isso antes de ser implantado em produção.
Como escrevi em um comentário anterior, em uma organização saudável a revisão de código deveria ser um entre vários processos responsáveis pela qualidade, e não o único portão que decide a implantação em produção. Em muitas equipes e empresas, os processos de garantia de qualidade depois do merge do código praticamente desapareceram.
Não se trata de diluir responsabilidades, mas de incorporar a qualidade ao processo desde antes de escrever código. São necessárias sessões Three Amigos, em que várias funções discutem especificações e requisitos, desenvolvimento orientado a testes, análise estática integrada ao IDE e a cada etapa de verificação, além de especialistas em garantia de qualidade e automação de testes separados dos desenvolvedores.
Na engenharia civil, uma única pessoa não é ao mesmo tempo projetista, construtora e única responsável por uma ponte. Há várias etapas: cálculos e documentação, recálculo, aprovação governamental, auditorias e inspeções durante a construção; até uma casa unifamiliar passa por plantas, aprovações, licenças e inspeções. Desastres de engenharia também muitas vezes são falhas do processo como um todo, que não foram barradas em várias etapas.
Se vamos comparar desenvolvimento de software com engenharia civil, também precisamos reconhecer que o nível de processo não é nem de longe o mesmo. Na melhor das hipóteses, muitas vezes estamos mais próximos de incorporadoras que constroem a casa mais barata possível contornando exigências legais.
Portanto, em software comum — fora áreas como software de controle de MRI — o ponto de compromisso entre custo de teste/validação e seu efeito inevitavelmente será diferente do da engenharia civil.
Os três textos são excelentes; recomendo a leitura. Também dá para ver as discussões anteriores:
https://lobste.rs/s/fv8swh/crossover_project (apresentação do projeto)
https://lobste.rs/s/lmvroa/are_we_really_engineers (nova discussão)
https://lobste.rs/s/8j8sdc/are_we_really_engineers (outra nova discussão)
Esta palestra de Glenn Vanderburg também é muito relacionada.
A maior diferença entre desenvolvimento de software e a engenharia tradicional é o atrito associado a mudanças. Software pode ser alterado de forma relativamente barata e é flexível, o que abre possibilidades completamente novas.
Quanto mais simulações a engenharia tradicional cria, mais ela também pode ampliar sua capacidade de mudança de modo parecido com o software, dentro dos limites físicos e químicos.
A afirmação “se é uma função de ordenação, não esperamos que ela ordene uma lista não patológica de números com apenas 95% de probabilidade” agora de fato se aplica a código gerado por LLM. Funciona na maior parte das vezes, mas não sempre.
Fico curioso para saber por que ~hwayne desativou a conta.