Enquanto meu talento reside no software, meus estudos de pós-graduação foram em engenharia informática (design e construção de computadores digitais). Uma observação sempre me pareceu: a engenharia da computação parecia mais direta do que a ciência da computação (software de construção). Há um conjunto de regras de design de engenharia a seguir e os projetos de engenharia são muito mais propensos a trabalhar do que projetos de software. Sim, há algumas falhas de engenharia espetaculares, mas, empiricamente, software confiável e útil é mais difícil de retirar. Para ilustrar o meu ponto, considere as incríveis sondas espaciais que enviamos ao longo do sistema solar. A própria nave espacial funciona muito bem, muitas vezes vivendo muito além das suas vidas de design. Seu software de controle, por outro lado, tem que ser constantemente ajustado e corrigido em vôo para manter a missão em conjunto. Não estou tentando dizer que a engenharia é fácil; não é. Meu objetivo é simplesmente explicar por que o software é mais difícil de obter do que os projetos de construção física em geral e por que "engenharia de software" é um termo inadequado.

A revista The Economist (27 de novembro de 2004, p. 71) cita as estimativas do grupo Standish que

...30% de todos os projetos de software são cancelados, quase metade vem no orçamento, 60% são considerados falhas pelas organizações que os iniciaram e 9 em cada 10 chegam tarde.

O artigo continua a salientar que, embora alguns grandes projetos de infraestrutura sejam concluídos no horário e no orçamento, você geralmente recebe algo no final. Você deve entrar no reino do software (ou militar) para gastar bilhões e não obter nada por isso. O maior motivo para este desperdício de perda reside nisso, enquanto um projeto de construção ou infraestrutura parcialmente concluído com falhas ainda pode ser útil, o software funciona ou não. Como o software é devidamente difícil de obter correto, muitas vezes acabamos com nada (por exemplo, FBI Dumps Reboque de Computador Botado, F.B.I. Enfrenta novo recuo na revisão do computador).

Por que escrever software não é como engenharia? A resposta reside numa única diferença fundamental com ramificações de longo alcance: a engenharia é restringida pelo mundo real, o mundo físico e o software não é. Embora óbvio, esta é a diferença crucial que explica por que o desenvolvimento de software é mais difícil de obter direito. As próximas secções exploram essas ramificações.

Componentes de engenharia existem no mundo real

Projetos de engenharia física são mais fáceis de visualizar e, portanto, mais fáceis de construir; heck, você pode realmente tocar os componentes e o produto final com as mãos. Quanto mais você se afasta da visão newtoniana do mundo físico que experimentamos no cotidiano, mais difícil é o projeto. A física quântica é difícil porque as partículas não se comportam como rochas. A teoria das cordas, o método mais promissor de modelagem da física quântica, é principalmente difícil de entender porque trata de seis ou sete dimensões extras além das três dimensões espaciais usuais. Imagine tentar projetar e construir uma casa em um Calabi-Yau Manifold (a imagem à direita é uma projeção 3-D).

O software nem tem o conceito de dimensão. Você pode dizer que não há linhas dentro das quais colorir. Pelo menos para projetos de engenharia acima do nível quântico, ninguém espera encontrar estruturas que "desafiem as leis da física". Isso limita o que você pode construir fisicamente e como você pode construí-lo, mas pelo menos fornece um mundo bem definido para trabalhar. O mundo etéreo do software não possui esse luxo, mas nossas ferramentas estão melhorando. A programação orientada a objetos foi inventada para tornar o software de escrita mais familiar para nossos cérebros de coletores de caçadores; ou seja, fazer componentes de software com propriedades e comportamentos como objetos no mundo real.

Componentes de engenharia interagem de maneira mais previsível

A engenharia é menos arriscada do que o software porque a engenharia experimenta menos interações de componentes componentes. Enquanto as mudanças menores em uma parte da estrutura de um carro podem afetar facilmente a robustez do choque de outra, seria incomum que uma falha de design na luz do domo causasse estantes intermitentes do motor. Em um projeto de construção de casa, você teria que trabalhar bastante para fazer uma descarga de toalete toda vez que alguém tocava a campainha.

Ao construir software, por outro lado, você tem que ser hipervigilante para evitar essas interações indesejáveis. Uma das razões pelas quais muitos programadores gostam de programação funcional pura é a falta de efeitos colaterais - simplesmente não há nenhuma maneira para o banheiro lavar inadvertidamente quando a campainha toca.

A situação é ainda pior em linguagens como C ++ sem proteção de transbordamento de buffer inerente. Um fragmento remoto de código pode involuntariamente alterar o comportamento da aplicação geral muito mais facilmente. Na verdade, é essa fraqueza particular que a maioria dos hackers exploram. Ao causar um estouro de buffer, um invasor pode forçar o programa a abrir um buraco nas suas defesas.

A engenharia tem menos alterações fundamentais no design do meio

A última razão pela qual o software é mais difícil de obter é certo do que os projetos de engenharia dizem respeito às mudanças no design do meio. O mundo físico não é tão maleável quanto o mundo insubstancial do software e, conseqüentemente, os clientes simplesmente têm expectativas mais baixas. O Congresso não vai para a NASA a meio caminho de uma moonshot e pede-lhes que venham a Marte em vez disso. A maioria dos projetos de engenharia pode realmente usar o método de design de cachoeira: determine requisitos funcionais, design, implementação, teste. Para a maioria dos projetos de software, esta é uma receita para o desastre.

Infelizmente, as mudanças de design no meio do caminho acontecem no software o tempo todo - sempre que o cliente recebe uma olhada no software em execução. De fato, o método ágil de desenvolvimento de software é uma resposta direta aos requisitos de design sempre em mudança. Os programadores são convidados a abraçar a mudança como uma oportunidade. Ainda assim, as mudanças constantes no design dificultam os esforços de desenvolvimento e os desenvolvedores devem constantemente refutar o software para evitar que ele se torne uma bagunça emaranhada e inquebrável.

Você pode perguntar por que, se o software for tão difícil de conseguir, os aviões não caem do céu. Acontece que eles ocasionalmente e o software ruim é muitas vezes o culpado; por exemplo., assista a um crash Airbus a320 fly-by-wire. Na maioria das vezes, no entanto, o software de controle de hardware para aviões, carros e dispositivos médicos funciona como esperado. O motivo da maior confiabilidade é triplo. Primeiro, há vidas em jogo e as pessoas provavelmente são mais cuidadosas. Em segundo lugar, os desenvolvedores de software não são solicitados a alterar o software fundamentalmente durante o desenvolvimento. Por exemplo, um avião dirigido por hélice não se torna um avião a jato no meio do desenvolvimento. Uma equipe de engenharia começaria de novo, enquanto uma equipe de software normalmente é solicitada a fazer mudanças radiais no meio do caminho. E, finalmente, esse software lida com o controle de dispositivos físicos e começa a ganhar algumas das vantagens oferecidas aos projetos de engenharia física.

O desenvolvimento de software é uma ciência?

Então, se o desenvolvimento de software não é como engenharia, o que é? Chamamos a disciplina de ciência da computação, mas não tenho certeza de que esse termo seja completamente apropriado. Você pode recordar a velha piada: "Se uma disciplina tem" ciência "no título, provavelmente não é". Na minha opinião, a ciência é sobre descobrir e descrever fenômenos físicos usando um método científico. Merriam-Webster descreve o método científico como:

Princípios e procedimentos para a busca sistemática de conhecimentos envolvendo o reconhecimento e a formulação de um problema, a coleta de dados através da observação e experiência e a formulação e teste de hipóteses.

Essa descrição chega de debugging mais que o ato de escrever software. A ciência da computação é sobre a construção de coisas como engenharia, mas sem o luxo de uma caixa de ferramentas e componentes retirados do mundo físico. Ninguém elaborou procedimentos confiáveis e eficazes para a construção de grandes peças de software, como os engenheiros fizeram para o projeto físico. Como afirma Alan Kay, o software é "engenharia de um tipo ... mas apenas feito pela força bruta". Uma conversa com Alan Kay:

Se você olha para o software hoje, através da lente da história da engenharia, certamente é uma engenharia de um tipo - mas é o tipo de engenharia que as pessoas sem o conceito do arco fizeram. A maioria dos softwares de hoje é muito parecido com uma pirâmide egípcia com milhões de tijolos empilhados uns sobre os outros, sem integridade estrutural, mas apenas feitos por força bruta e milhares de escravos.

Escrever software é mais uma arte do que uma disciplina de engenharia

O software de escrita é mais parecido com a escrita de novelas de ficção. Escrever romances também é um ato de criação em um meio sem restrições e eéreas com poucas regras de construção bem estabelecidas. Conhecemos uma boa escrita quando a vemos, mas é difícil de ensinar. A experiência de escrita e comentários de escritores melhores (codificadores) é o meio mais confiável de se tornar um bom escritor (codificador). Sem um processo bem compreendido, o software permanecerá mais uma arte do que uma ciência. O termo "engenharia de software" é mais um objetivo do que a forma como realmente escrevemos software.