Engenharia Civil vs Engenharia de Software

[odon.rafael]

Tive uma discussão interessante aqui na empresa sobre Low Code que culminou no seguinte desabafo meu: “As vezes no silêncio da noite, eu fico imaginando como a engenharia de software é volátil em relação à engenharia civil. Não bastasse a metodologia de uma ser mais confiável que da outra, o produto de uma também é inferior ao da outra sob determinados aspectos. Uma construção civil em geral é estável, robusta, duradoura e quase sempre manutenível (se isso se fizer necessário). O sistema de informação por sua vez é uma entidade frágil, perecível e instável e o processo que ele tenta informatizar é uma coisa viva e mutável. Se o sistema ganha a briga, engessa o processo. Se o processo ganha a briga, inutiliza o sistema.”

Um colega ainda adicionou: “Se um projeto de engenharia civil falha, prédios caem, pessoas morrem, o engenheiro vai preso. Se um projeto de engenharia de software falha, não importa quão ridiculamente, os criadores são condenados a mantê-lo (ou repassar a codebase para algum infeliz manter…)”.

E outro disse ainda: “E digo mais… no meio da construção de uma ponte o cliente não pede para a ponte ser transformada um prédio de 100 andares!”

Comentem.

[kicolobo]

Esta sempre foi pra mim uma das comparações mais nocivas em relação à nossa área, mas já que estamos comparando, vamos lá!

Responsabilidade

A primeira diferença pra mim é a questão da responsabilidade: quem mencionou isto tá coberto de razão. Programador se esquece que software não raro mata e ninguém sofre consequência alguma.

Além de matar também destrói vidas, sonhos, negócios quando é mal feito e, pro meu horror, as pessoas simplesmente não pensam nisto. Na minha opinião deveriam existir entidades responsáveis por validar se o software é bem projetado e construído, tipo o CREA. Não estou falando em regulamentar a construção, mas de um QA realmente profissional (algo que nunca vi).

Cinco anos atrás escrevi sobre isto, aliás: https://www.itexto.net/devkico/?p=1741

Previsibilidade

Aqui na minha opinião é aonde o bicho pega. Software, ao contrário da construção civil é imprevisível por natureza e portanto não devíamos sequer pensar nesta comparação.

Se vou construir uma parede, consigo facilmente prever quanto tempo leva pra que ela seja levantada: os tijolos tem tamanho similar (o mesmo na maior parte das vezes), a área a ser construída é conhecida de antemão e você sabe claramente quantos tijolos o operário consegue colocar na parede por hora. Logo, no que diz respeito à construção, dá pra prever.

Agora, será que consigo prever o mesmo no que diz respeito ao trabalho do arquiteto? Não entendo porra nenhuma de construção civil, mas acredito que não. Então, vamos ao software.

No caso do software, todo mundo deveria ser operário no sentido de que todo mundo deveria saber construir (programar) neste ofício. E aqui entra aquilo que é lindo e traumático no software: toda pessoa é diferente e portanto não podem ser pensadas de uma forma massificada.

Não sei se já notaram, mas já perceberam que os piores gerentes são aqueles que usam o termo “recurso” pra se referir à sua equipe de desenvolvimento. Frases como “disponibilizei seis recursos” aos meus ouvidos soam como o alerta: perdido gerenciando.

Software não é previsível por causa disto: qualquer problema pode ser resolvido de inúmeras maneiras, por que as pessoas pensam de inúmeras maneiras, e é isto que torna a coisa linda.

E ainda há outro ponto aí. Sabe aquele papo do “programador 1000x” que muita gente diz que é mentira? Pois é: é verdade. PURA verdade.

Se você pega, por exemplo, um padeiro muito ruim e um padeiro muito bom, no que diz respeito à produtividade, a diferença entre os dois não deve ser grande coisa. Sei lá: 20, 30%. Quando se fala de gente que programa, a situação muda. Tem aquela pessoa que resolve o problema em 10 minutos de forma brilhante, e a outra que leva dias.

E pra piorar, você ainda tem variações de humor. Se você pensa em software como matemática… tá falando merda, não sabe do que tá falando.

Sobre a qualidade

Aí já discordo demais. É possível ter critérios bem objetivos pra coisa, é só saber do que se está falando.

[odon.rafael]

Boas considerações @kicolobo. Quando essa comparação brota na minha cabeça quase sempre é por um sentimento de inveja, de admirar essa previsibilidade das outras engenharias, e não no sentido de nivelar nossa engenharia pelas outras, justamente pois nosso produto é muito melindroso.

Além de matar também destrói vidas, sonhos, negócios quando é mal feito e, pro meu horror, as pessoas simplesmente não pensam nisto. Na minha opinião deveriam existir entidades responsáveis por validar se o software é bem projetado e construído, tipo o CREA. Não estou falando em regulamentar a construção, mas de um QA realmente profissional (algo que nunca vi).

Exato, sempre refleti sobre esse ponto. Sei de um caso real de um sistema que gerencia um hospital e que, pelas histórias relatadas pelos seus usuários, certamente mata pessoas ou ajuda a matar. Mesmo que não cheguemos a esse extremo de brincar com a vida/morte, quantos não são os sistemas que sustentam o negócio de algumas empresas e cujos problemas, falhas e ineficiências representam indiretamente perdas financeiras. Logo, eles influenciam a vida de muitas pessoas (a empresa pode desempenhar mal e demitir pessoas por exemplo).

[luizlh]

Concordo com quase tudo que o @kicolobo escreveu, mas não concordo em existir um CREA, até porque, o que eles vão atestar? que um Engenheiro de Software poderá se responsabilizar por um projeto de software?

Um QA profissional, isso sim é o ideal, nos EUA já começa aparecer empresas que estão oferecendo este tipo de serviço.

O que eles oferecem é uma auditoria técnica gerando um relatório sobre o estado atual do projeto de software.
Segue link abaixo de uma dessas iniciativas, muito interessante a proposta.

Tech Audit

Se quiserem saber mais, vale a pena acompanhar as ideias do Yegor Bugayenko, autor do audit.zerocracy, ele escreve sobre qualidade de software e trabalha com projetos em Java segue link do blog dele.

Yegor's Blog About Computers

[kicolobo]

A gente então concorda inteiramente: é justamente isto o que imaginava que deveria existir, valeu pelos links!

[ronaldo.faria.lima]

Gostaria de acrescentar algumas considerações. A imprevisibilidade de um projeto de software existe por conta do conhecimento. Quando você começa a construir um software, você não tem todo o conhecimento necessário para construir o projeto, principalmente por que as condições mudam. E quando falo conhecimento não estou me referindo à tecnologia, mas do negócio.

Todo software é a automação de um processo arbitrário de negócio. Nós, profissionais de TI, conhecemos do nosso ofício, mas não conhecemos o negócio do nosso cliente. Mesmo o cliente desconhece todo o processo de negócio que pode ser arbitrariamente complexo, com procedimentos que somente algumas pessoas conhecem. Via de regra, os processos de negócio não são documentados e cada pessoa envolvida acaba atuando de uma forma particular, o que torna o levantamento de requisitos particularmente complexo.

Não apenas isso, mas o negócio é mutável. Quando você está no meio do projeto o negócio do cliente já sofreu alterações e não é incomum o software ir para a produção desatualizado com relação a várias regras que surgiram no meio do caminho.

O modelo de dados, por exemplo, é quem mais sofre com as mudanças no negócio. Impactos no modelo são sempre os que mais causam impacto no sistema como um todo. Por isso é tão difícil, na minha opinião, prever as coisas em um projeto de software: o negócio do cliente está sempre mudando, o que implica em um modelo altamente volátil.

[jcbritobr]

Talvez digam isso porque na engenharia civil você só trabalhe numa escala realmente macro. A engenharia de software é mais flexível e se projetam soluções simples até às realmente muito críticas no cenário aero espacial e militar. Imagino que seja uma certa ignorância em notar que hoje quase tudo no mundo seja microcontrolavel.