Continuando com o assunto da metáfora errada, software é conhecimento inserido no meio digital. Sendo assim, é fluído. Edifícios, por outro lado, são estruturas estáticas em um mundo físico. Apesar disso, muitos comparam fazer software com construir prédios ou casas. Esse é um erro grave!

Ao longo do tempo, a informática desenvolveu uma crescente inveja pela engenharia civil. Engenheiros conseguem projetar prédios que não caem e são capazes de construí-los dentro do prazo e do orçamento. Profissionais de computação, por outro lado, raramente conseguem construir sistemas bem feitos, que dirá dentro do prazo e do orçamento. “Se ao menos nós adotássemos conceitos da engenharia, talvez conseguíssemos ser tão bem sucedidos quanto os engenheiros são na construção de edifícios”. Pelo menos isso é o que se pensou, de forma equivocada.

Imitar a engenharia é o que vem sendo tentado há décadas. E o resultado tem sido péssimo, por várias razões. Talvez uma das mais importantes seja exatamente a natureza do que se está construindo. Fazer software é diferente de construir prédios, porque a natureza de um é completamente distinta da do outro. Prédio é físico, software é digital. As técnicas que se aplicam a um não se aplicam ao outro. Fazer software como se faz prédios é como ir para a prova de biologia tendo estudado a matéria de matemática.

Ao final da construção de um edifício, seria possível pedir aos construtores que movessem o prédio um metro para a esquerda? Normalmente não. Por outro lado, seria possível “mover um aplicativo um metro para a esquerda”? Tipicamente sim. Não é possível comprar um livro na Amazon e esperar que chegue até você dois minutos depois. Mas é possível fazer o download de um livro em PDF, de qualquer lugar do planeta, em poucos instantes.

O mundo digital é diferente do físico. Um livro comprado na Amazon terá que passar por inúmeras etapas para chegar até você. Entre outras, será empacotado, colocado em um caminhão, depois em um navio, e então passará pela alfândega, para finalmente ser colocado em um novo caminhão e entregue na sua casa. As etapas são mais complexas, mas já dá para perceber que o caminho é tortuoso.

O livro em PDF também passa por vários servidores e redes distintas até chegar ao seu computador. Mas como são apenas bytes em movimento, ao invés de elementos físicos, todo esse trajeto pode ser feito em menos tempo e com um custo insignificante.

Enquanto o livro físico tem que passar por inúmeros obstáculos que emperram e atrasam seu movimento, o livro digital, em PDF, flui rapidamente de uma máquina para outra. Portanto, fluidez faz parte da natureza básica de um software.

Escrever um livro não é um processo linear. Ou seja, embora possa até ter um plano do que será escrito, o autor não começa a escrever no primeiro capítulo e segue linearmente até a conclusão. Cada autor tem sua abordagem própria, mas uma coisa todos têm em comum. Em um momento estão escrevendo sobre novos assuntos, no outro estão revisando e aprimorando o que já havia sido escrito. Há um processo contínuo de ida e vinda. Da mesma forma que ele avança, ele também volta atrás e descobre formas de expressar melhor suas ideias. Até mesmo a escrita de uma simples redação passa por esse processo.

Ir e vir é natural na escrita, já que nela, alterar o que foi feito tem baixo custo e leva pouco tempo (especialmente comparando-se à construção de um prédio). Esse processo de ir e vir, que rege o mundo do conhecimento, não é adequado ao mundo físico. Não se pode construir um prédio dessa forma. É inconcebível levantar três andares e depois colocar tudo abaixo porque aprimoramos nosso conhecimento sobre o edifício. Tal abordagem seria excessivamente cara, demorada e arriscada. Mas software não é prédio; novamente, software é digital. Portanto, ir e vir é economicamente viável e natural. De fato, o que mais se observa no desenvolvimento de software é a presença de mudanças. Elas ocorrem porque há um processo contínuo de aprendizado em ação. Clientes aprendem, desenvolvedores aprendem, usuários aprendem e todos esperam que o aprendizado seja canalizado para o software em construção. Todos acreditam, intuitivamente, que alterar o software é barato. E, de fato, tende a ser, sobretudo comparado ao custo de fazer alterações significativas em estruturas físicas.

O máximo que você pode fazer é usar as imagens de uma construção civil apenas de forma ilustrativa, da mesma forma que eu faço neste artigo e no meu blog em geral. Fora isso, não construa um software seguindo valores e princípios da engenharia civil, porque a história e as estatísticas já provaram que não funcionou e por que que não irá funcionar.