O que engenheiros de software podem aprender com engenheiros de outras áreas?

Publicado originalmente no Linkedin em março/2019

Nas últimas décadas nós (os devs) ganhamos muitos papéis nos times de desenvolvimento, dentre eles temos o programador, analista de sistemas, arquiteto de software, dev backend, frontend, fullstack e um que atualmente está em evidência, o engenheiro de software. Esses papéis vieram para organizar as várias atividades que exercemos, mas a de engenheiro de software é a que pretendo aprofundar.

A figura do engenheiro está presente em muitas áreas como a construção civil, mecânica, elétrica, dentre outras, em todas elas é necessário uma formação mínima para exercer a profissão requerendo geralmente até registro em órgãos regulamentadores da área. Um engenheiro nessas áreas precisa seguir padrões, se adequar a metodologias e principalmente se tornar responsável pelos projetos realizados vinculando seu nome e registro.

Comparando a área de software com as demais áreas temos algumas facilidades para o engenheiro, pois não há necessariamente uma formação mínima, não há necessidade de se registrar, vincular o nome a um projeto se torna mero capricho. Mas não é o foco aqui dizer que isto é bom ou não, o que desejo trazer aqui é uma reflexão sobre quais pontos os engenheiros de outras áreas fazem bem e que o engenheiro de software também pode fazer.

Antes de apresentar tais pontos, quero ainda deixar um questionamento para você. Quantas vezes você já “xingou” um engenheiro (mesmo sem conhecê-lo) afirmando:

• Quem foi o cara que projetou isso aqui? Ele merecia uma surra.
• O cara que projetou isso aqui nunca utilizou!
• Quem projetou isso aqui, comprou o diploma!

Essas frases também são ditas aos engenheiros de software, e infelizmente muitas vezes elas tem um fundo de verdade. Para mudar esta visão e evitar essas frases segue alguns pontos aos quais podem ajudar no amadurecimento do engenheiro de software:

• Padrões: Esse é um dos pontos mais importantes. Todo engenheiro em qualquer área segue padrões e evita criar formas mirabolantes de resolver um problema. Temos então algumas perguntas ao engenheiro de software: você procurar usar padrões? quantos livros relacionados a padrões de software você já leu? Se já leu, quantos destes padrões você aplica de fato no dia a dia? Os padrões ajudam a resolver problemas de forma com que todos entendam o como esse problema foi resolvido!
• Formação: A área de software permite métodos alternativos para se ter uma formação profissional e muitas vezes sequer isso é necessário para se tornar um engenheiro de software. Essa facilidade não deveria afastá-lo dos meios formais de ensino. É importante ler artigos, tutoriais, livros, mas mais ainda trocar conhecimento com outros engenheiros, inclusive os que estão no universo acadêmico. É importante que se compreenda o conceito das coisas antes de sair aplicando. Um engenheiro de software deve ter esse papel muito mais pelo conhecimento e aplicação do mesmo do que por “tempo de profissão como dev”.
• Planejamento: Uma prática esperada dos engenheiros é a de planejar antes de executar o projeto. Isso se faz através de análise do problema, estudos de casos, desenhos técnicos, simulações, etc. Na área de software muitas destas etapas são ignoradas e com isso muitos problemas surgem durante a execução do projeto ou pior ainda, depois que ele é dado como pronto. Então planejar bem o desenvolvimento de um software é essencial para o sucesso da execução do projeto e principalmente para evitar as frases citadas no início do artigo.
• Documentação: O engenheiro em outras áreas geralmente documenta muito bem o projeto. Essa documentação tem várias finalidades, dentre elas registrar o que se pretende fazer, quais critérios usados na tomada de decisão, resultados esperados. Além disso possibilitar que as pessoas tenham visão completa do projeto e que outros profissionais posteriormente não precisem recorrer ao engenheiro para compreender o que foi feito. Enfim, nas demais áreas ter um projeto devidamente documentado é quase sempre pré-requisito para a sequência do projeto. Na área de software isso é considerado burocracia ou perda de tempo. Mas é possível fazer isso de forma adequada na área de software, não abra mão da documentação, busque alternativas para que ela tenha validade e prove seu valor.
• Assinar um projeto: Nas demais áreas um engenheiro geralmente precisa “assinar” o projeto. Isso o torna responsável pelas decisões que foram tomadas e faz com que ele pense bem antes de decidir por opções de baixa qualidade ou fora dos padrões. Na área de software geralmente essa questão é ignorada e com o tempo ninguém mais sabe “quem foi o responsável por essa decisão”, e embora tenhamos o nome de quem fez o commit do código, muitas vezes esse não é o nome do engenheiro. Isso abre espaço para decisões sem qualquer responsabilidade, o que a médio e longo prazo se torna um dos grandes fatores da baixa qualidade dos softwares que são produzidos.

Enfim, há vários outros pontos, mas esse artigo certamente ficaria extenso demais. O fato é que na área de software muitos paradigmas foram quebrados com relação a burocracia e formação de um profissional na área, o que estimulou a inovação e escala da área como um todo. Porém isso não deve ser um pretexto para ignorar boas práticas que os engenheiros de outras áreas tem para construção e execução de projetos com qualidade.

Aplicar todos esses itens não é fácil, ainda mais porque geralmente não há um processo formal que obrigue isso e assim deixamos alguns de lado ou pecamos na aplicação por falta de conhecimento ou maturidade.

A engenharia de software é uma área muito nova se comparada a outras engenharias. Além disso as mudanças e evoluções na área de software são muito mais rápidas e disruptivas. Então é natural que a área e o engenheiro de software precisem ainda amadurecer e consolidar vários destes pontos, a mensagem final que deixo é que certamente esse amadurecimento pode ser conquistado e acelerado se buscarmos aprender com engenheiros de outras áreas!

Link para publicação original no Linkedin: https://www.linkedin.com/pulse/o-que-engenheiros-de-software-podem-aprender-com-felisberto-de-souza/