Software (Engenharia ou Desenvolvimento?)
Esse post foi traduzido automaticamente do inglês. Se você encontrar algum erro, por favor entre em contato.
Uma coisa que sempre me interessa sobre software é a eterna discussão, que já dura alguns anos, sobre a relação entre desenvolvimento de software e outras disciplinas de engenharia.
De um lado estão os adeptos da abordagem tradicional, afirmando que projetos de software são iguais a qualquer outro projeto de engenharia e que, por isso, deveriam ser gerenciados como outros projetos de engenharia (o favorito é a engenharia civil, com a construção de casas).
Do outro lado, os praticantes ágeis não aceitam que desenvolvimento de software seja chamado de “engenharia”, e dizem que essa é provavelmente uma das razões pelas quais o desenvolvimento de software está na situação atual (não é boa, como você pode concluir).
Então, qual é a resposta certa? Na minha opinião, as duas! Vamos à explicação…
Martin Fowler escreveu algo sobre isso neste artigo, onde explica por que a abordagem tradicional de engenharia civil não pode funcionar no desenvolvimento de software:
É possível criar um design capaz de transformar a codificação em uma atividade de construção previsível? E se sim, o custo de fazer isso é pequeno o suficiente para tornar essa abordagem viável?
E eu concordo totalmente com ele. Se você olhar para modelos UML e outras metodologias de design de software, não há como projetar um software com tantos detalhes a ponto de a fase de construção poder ser uma atividade menos qualificada, com resultados previsíveis. Tudo o que se obtém em projetos com longas fases de design é muito retrabalho na fase de construção.
Ok, então software não é engenharia civil, mas não é engenharia de forma alguma? Isso ficou mais claro depois de ler o apêndice F do Relatório da Comissão Rogers, escrito por Richard Feynman, que investigou o desastre do ônibus espacial Challenger em 1986.
Agora, se você ainda está prestando atenção, deve estar perguntando: o que ônibus espaciais têm a ver com software?
Simples, é engenharia. E não apenas isso, é engenharia de alta tecnologia.
Veja o que o Dr. Feynman disse em seu relatório sobre o motor principal do ônibus espacial:
O Motor Principal do Ônibus Espacial foi tratado de maneira diferente, de cima para baixo, poderíamos dizer. O motor foi projetado e montado de uma vez só, com relativamente pouco estudo preliminar detalhado dos materiais e componentes.
Isso soa familiar? Que tal a abordagem alternativa:
A maneira usual como esses motores são projetados (para aeronaves militares ou civis) pode ser chamada de sistema de componentes, ou design de baixo para cima. Primeiro é necessário entender completamente as propriedades e limitações dos materiais a serem usados…
Com esse conhecimento, partes maiores dos componentes (como rolamentos) são projetadas e testadas individualmente. À medida que deficiências e erros de design são notados, eles são corrigidos e verificados com mais testes. Como se testa apenas partes de cada vez, esses testes e modificações não são excessivamente caros. Finalmente, chega-se ao design final do motor completo. Há uma boa chance, a essa altura, de que o motor funcione bem, ou que quaisquer falhas sejam facilmente isoladas e analisadas porque os modos de falha e as limitações dos materiais são tão bem compreendidos.
Bom, quando li isso, me pareceu que alguém estava falando sobre desenvolvimento iterativo de software. E esse é o ponto central: desenvolvimento de software pode ser comparado a uma disciplina de engenharia, mas a uma disciplina de engenharia avançada.
Se você tentar comparar desenvolvimento de software com construção de casas, está tentando comparar 2000 anos de experiência com algo que começamos a fazer no século passado. Mas mesmo em software, se você vai para domínios bem conhecidos, com tecnologias bem conhecidas, provavelmente pode automatizar o processo com diferentes ferramentas, tornando-o uma “tarefa menos qualificada” e também muito mais fácil.
Mas na grande maioria dos projetos, desenvolver software ainda é lidar com tecnologias recém-descobertas e domínios em constante mudança, e é isso que o torna tão difícil.
Então, apenas para fazer um ponto final, desenvolvimento de software é ciência de foguetes!