Eu uso o termo “engenharia de software”. Quem já viu uma palestra minha, leu um artigo, ou frequenta este blog sabe disso. Só que já tem um tempo que tenho um certo problema com o termo. Principalmente porque o termo “engenharia” parece carregar práticas que não se aplicam em sua totalidade à criação de algo tão etéreo como software. Nas palestras que dou sobre engenharia de software ou processos logo no começo eu deixo claro que há uma grande diferença entre o que fazemos e o que um engenheiro civil faz. Comparo a criação de software com a construção de uma ponte e também com o litigar de um caso na justiça, e ressalto que há elementos de um, como de outro, mas que ainda assim não é um, como não é o outro. Eu mudei de idéia. Não me incomodo mais com o termo. Quem me fez mudar de idéia foi a segunda edição do livro “Agile Software Development – The Cooperative Game” do Alistair Cockburn. Estou gostando muito do livro, e ele entra nesta discussão, perguntando se desenvolvimento de software é ou não engenharia. A resposta é: sim, é; e faz sentido. A questão é que normalmente vemos engenharia de software como “ciências aplicadas”. O engenheiro é alguém com profundo conhecimento de matemática, física, química, e talvez outras ciências naturais, que faz uso deste conhecimento para criar coisas materiais. Ele utiliza seu conhecimento de física e de determinado material para determinar o tamanho de uma viga, dada a carga que ela vai ter que suportar, por exemplo. Só que o engenheiro não é só isso. É verdade que o engenheiro deve aplicar o conhecimento das ciências naturais para resolver os problemas que encontra. Mas isso não significa que as perguntas que ele deve fazer para resolver os problemas com o qual ele se depara vêem tão matematicamente quanto as respostas para tais perguntas, ou ainda que ele as formule sozinho. O que normalmente acontece é que um engenheiro, independentemente da área, terá que buscar de maneira criativa a pergunta correta para resolver um problema. Somente depois de fazer a pergunta certa – e pode haver mais de uma, cada uma resolvendo o problema com diferentes graus de exatidão – é que ele vai poder aplicar seus conhecimentos das ciências exatas. Até então ele está trabalhando criativamente, utilizando o conhecimento das ciências exatas em conjunto com diversos outros, combinando-os de maneiras aleatórias, ou utilizando técnicas de análise, para chegar em perguntas candidatas, que podem ser testadas, ou não, até que uma seja escolhida como a mais apropriada. E depois de resolver a pergunta escolhida, ela pode acabar não atendendo o problema de maneira satisfatória, e o processo começa de novo, só que desta vez após um grande processo de aprendizado ter acontecido, com um engenheiro agora mais preparado, e que vai olhar suas opções com mais abrangência e profundidade do que aconteceu na primeira iteração. O conhecimento gerado com a primeira iteração, tenha ela tido sucesso ou não, não tem preço, e só pode ser ganho desta forma, e não lendo um documento com as experiências de outra pessoa, por exemplo. Experiência não se compra. Esse processo ocorre também em grupos, onde um time de engenheiros, e possivelmente alguns não-engenheiros, se reune para discutir um problema, e como vão resolvê-lo. Nesse caso, além de todo o processo de criatividade e invenção já citado, há ainda todo o processo de comunicação, que nada tem a ver com uma ciência natural como a física ou a matemática. O problema é sempre formulado por alguém, que não é o engenheiro. Isso significa que o engenheiro nunca está só, e o processo de comunicação sempre existe. E se há comunicação estamos abrindo as portas para atividades que nada tem a ver com matemática ou física. Assuntos como negociação, persuação, hierarquia, relacionamento interpessoal, entre outros, passam a preocupar o engenheiro, que não deve mais se restringir a números, vigas, ou a resistência de materiais. Diante desta visão, fica mais fácil dizer que engenharia de software existe, sim. Da mesma forma, temos atividades mais exatas, como a aplicação de algum padrão de projeto, ou de polimorfismo, por exemplo, mas temos também atividades relacionadas a comunicação, como reuniões diárias, e o pareamento. Nesses momentos estamos trabalhando nossa capacidade inventiva e comunicativa para buscar as perguntas corretas para atender determinado caso de uso história. Nesse cenário o engenheiro civil é mais parecido com o engenheiro de software do que pensávamos; temos os processos mais exatos, mas eles são somente parte da prática, já que temos também os processos inventivos e comunicativos. Você, como desenvolvedor de software que me lê agora, deve à sua profissão se aprimorar em ambos os lados da sua prática, o humano, e o exato. E então poderá se qualificar como um engenheiro. (Quantas faculdades de engenheria será que expõe os alunos a processos que não tocam somente as ciências exatas, mas tocam também em assuntos como liderança, criatividade, negociação, entre outros? Será que podemos qualificá-las como verdadeiros cursos de engenharia?)

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.