O que realmente significa ser um Engenheiro de Software?

#softwareengineering #history

Introdução

Iniciei minha carreira na área de TI por volta de 2018, enquanto ainda era estudante. Após alguns anos, já no meu primeiro emprego, comecei a me autodenominar "Engenheiro de Software" nas redes sociais. Não, esse não era meu título profissional, nem eu compreendia completamente seu significado; simplesmente gostava da seriedade e experiência que essa designação conferia aos meus perfis online.

Caso o leitor se identifique com minha experiência (ou não, também 😅), esta redação será de seu agrado. Nela, busco contextualizar a filosofia e a história por trás dos títulos e cargos utilizados por todos nós, "povo da computação", e, ao final, tento trazer luz a esse tema tão raramente discutido.

Nota ao leitor

Antes de prosseguir com a leitura, é importante esclarecer alguns pontos:

Este texto pode ser categorizado como uma crítica, porém não é direcionado a ninguém ou a nenhum grupo específico (exceto aos profissionais da área computacional). Portanto, peço que o leitor o encare apenas como um artefato informativo;
A pesquisa foi realizada deliberadamente por mim, movido pela curiosidade. Portanto, não considere tudo que é apresentado aqui como dogma. Faça sua própria pesquisa e verifique as referências antes de aceitar qualquer informação;
Tentei ser o mais didático possível, incluindo referências e sendo crítico em minhas opiniões. No entanto, sou humano e posso estar equivocado. As críticas não apenas são bem-vindas, como também são necessárias;

Conferências de Garmisch

Em 1968, o Comitê de Ciência da NATO (Organização do Tratado do Atlântico Norte) organizou algumas conferências em Garmisch, na Alemanha, onde mais de 50 participantes internacionais discutiram sobre os problemas emergentes dos softwares da época. Devido à evolução não apenas das tecnologias disponíveis, mas também dos problemas reais que essas tecnologias enfrentavam, tornou-se urgentemente necessário o desenvolvimento e a regulamentação de uma nova metodologia capaz de produzir Software para suprir as necessidades da sociedade moderna (NAUR; RANDELL, 1969).

Embora o conceito de "Engenharia de Software" por si só não tenha sido o único tema discutido nessas conferências, muito menos o produto final, elas foram determinantes para a valorização e popularização dessa nova disciplina com o passar do tempo. Nas palavras de Margaret Hamilton (HANCOCK, 2014):

Quando comecei a usar essa expressão [Engenharia de Software], ela era considerada um tanto engraçada. Foi motivo de piada por um bom tempo. Eles [provavelmente outros desenvolvedores do Apollo Guide Computer] gostavam de brincar comigo sobre minhas ideias radicais. O Software eventualmente e necessariamente ganhou o mesmo respeito que as outras disciplinas.

-- Margaret Hamilton, entrevista para El País, 2014

Claramente, as conferências foram uma resposta a um contexto da época. Portanto, é importante, antes de prosseguirmos, esclarecer por que o conceito de "Engenharia de Software" encontrou resistência durante sua concepção e implementação.

As três tradições da computação

Apesar de ser uma disciplina relativamente nova, a computação, em seu primeiro século de existência, passou e ainda passa por transformações e ramificações únicas, fazendo da Engenharia de Software um conglomerado de outras disciplinas que, simultaneamente, se complementam e disputam entre si (TEDRE; SUTINEN, 2008). São elas:

Tradição Matemática: programas são tratados como objetos abstratos, estruturas teóricas e sistemas axiomáticos que avaliam de maneira booleana. (MCCARTHY, 1960) é um ótimo exemplo de uma definição de um software com uma grande influência da tradição matemática;
Tradição Científica: programas são tratados como modelos de informação que buscam, seguindo algum sistema científico idealizado, satisfazer dados que comprovam uma hipótese ou seguem o processo científico;
Tradição da Engenharia: programas são processos que afetam e são afetados pelo mundo real. Trata-se da agregação de sistemas computacionais existentes de forma a produzir um novo sistema;

É interessante ressaltar que muitas autoridades têm formulado diversos argumentos e contra-argumentos para cada uma das tradições detalhadas. Um dos exemplos mais difundidos é o do Prof. Dr. Edsger Dijkstra, renomado matemático por trás de muitos fundamentos da computação, que definiu a Engenharia de Software, em seu ensaio "Sobre a crueldade de realmente ensinar Ciência da Computação" (E.W. DIJKSTRA ARCHIVE, 2023), como "A Disciplina Condenada":

Assim como a economia é conhecida como "A Ciência Miserável", a Engenharia de Software deveria ser conhecida como "A Disciplina Condenada"; condenada porque nem chega perto de atingir seu objetivo, já que seu objetivo é contraditório por si próprio. Claramente, a Engenharia de Software se apresenta como uma causa válida, mas isso é enganação: se você ler sua literatura e analisar o que seus devotos realmente fazem, descobrirá que a Engenharia de Software aceitou como sua missão "Como programar se você não o sabe.".

-- Edsger W. Dijkstra, EWD 1036

Em contraste, detalharei alguns argumentos que não buscam provar a superioridade da tradição da engenharia, mas sim demonstrar a necessidade de sua existência quando comparada às outras disciplinas:

Modelos Teóricos vs. Mundo Real

Se o leitor estiver familiarizado com teorias dualistas, idealistas, fenomenológicas, platônicas (por ex. PLATO, 1986) ou neoplatônicas, terá mais facilidade em reconhecer a validade deste primeiro argumento.

A matemática trata principalmente de abstrações teóricas que, em sua maioria, mas não necessariamente, correspondem aos fenômenos naturais (THOMAS; MAURER, 1986). Com essa definição em mente, surge naturalmente um problema quando a matemática é aplicada à computação: Modelos teóricos de programas podem ser validados puramente de forma axiomática; o mesmo programa em execução em uma máquina entra em contato com variáveis naturais que impossibilitam sua validação (TEDRE; SUTINEN, 2008, p. 156). Não existe sequer um modelo matemático que consiga provar (exceto em teoria) com 100% de certeza como os elétrons de um computador se comportarão durante a execução do mesmo programa (TEDRE; SUTINEN, 2008, p. 157).

Imagine que o leitor está executando o programa mais bem testado do mundo no computador mais confiável do mundo. De repente, um terremoto de nível 9 na escala Richter ocorre, seguido por uma chuva contínua; alguns segundos depois, o sol explode e incendeia tudo o que existe... Deseje boa sorte aos modelos teóricos.

Sim, este exemplo está longe de acontecer. No entanto, a ideia continua sendo verdadeira: não controlamos, nem conseguimos prever todas as variáveis do universo. Nenhum programa em execução é 100% eficaz.

Ao reconhecer essa diferença, a Engenharia de Software procura lidar da melhor maneira possível com esses problemas do mundo real. Não é à toa que desenvolvemos e aprimoramos algoritmos como os de tolerância a falhas, replicação, consenso, balanceamento de carga, etc., que compõem os sistemas que fazem a sociedade atual funcionar. O leitor talvez se recorde das primeiras máquinas computacionais do início do século passado: sistemas elétricos enormes que falhavam constantemente. Sem a influência dos engenheiros elétricos, é discutível a hipótese de que a computação estaria, ainda hoje, nos gabinetes teóricos da matemática (TEDRE; SUTINEN, 2008, pp. 161-162).

Processo Científico vs. Construção de Software

Aqui entramos em um território altamente contraditório, completamente fora da minha atual autoridade para argumentar de forma a adicionar qualquer progresso: "O território das Definições Inacabadas".

A ciência em si é um conceito amplo que, consequentemente, possui diversas lacunas de definição autoritárias como "O que é ciência?" ou "Qual o modelo ideal de processo científico?". Esta falta de definição (que por sua vez não é algo necessariamente ruim ou proveniente de inexperiência, mas sim da natureza da filosofia e dos limites humanos em geral) torna possível que uma questão em específico emerja: A computação pode ser considerada, por definição, uma ciência? Ou até mais, uma ciência natural? Em outras palavras, levando em conta a definição de que as ciências naturais tratam da observação e estudo de fenômenos naturais (THOMAS; MAURER, 1986), é possível categorizar a ciência da computação como uma?

Diversos autores têm adentrado em detalhes acerca desse questionamento e o debatido. Entretanto, irei focar em apenas um contestamento, para que possamos avançar no fortalecimento da nossa visão atual sobre a Engenharia de Software.

O contra-argumento mais difundido é de que a computação não procura estudar um fenômeno natural de forma a produzir um mais amplo entendimento do mundo. Em realidade, os únicos dados e fenômenos observados são, em suma, o computador e seus processos, os quais já são muito bem entendidos na disciplina. Isso torna a pesquisa não um entendimento acerca dos fenômenos naturais, mas sim de fenômenos artificiais que não apenas são entendidos, como também foram criados. Segundo esse contra-argumento, a única resolução dessas pesquisas é validar o quão bem os últimos pesquisadores construíram seus Softwares (HARTMANIS, 1993).

Considerando também este ponto, a Engenharia de Software entende sua artificialidade e suas limitações de pesquisa, procurando voltar seus métodos de aprimoramento especialmente para o entendimento dos sistemas computacionais já existentes.

Conclusão

Meu objetivo inicial ao começar a escrever este ensaio era apenas sanar minha curiosidade. Porém, conforme o texto foi se preenchendo, julguei inconveniente não compartilhar o conhecimento adquirido.

Como foi requisitado na introdução, eu espero que a leitura tenha sanado lacunas de conhecimento que o leitor possuísse, e que finalmente entenda o porquê de nos chamarmos Engenheiros de Software.

Obrigado pelo seu tempo. Não hesite em comentar qualquer dúvida ou opinião!

Josué Teodoro Moreira
https://j0suetm.com, teodoro.josue@pm.me, https://www.linkedin.com/in/josue-teodoro-moreira/

Referências Bibliográficas

MCCARTHY, J. Recursive functions symbolic expressions and their computation by machine, Part I. Communications of the ACM, v. 3, n. 4, p. 184–195, 1 abr. 1960.
HANCOCK, Jaime Rubio. Margaret Hamilton, la pionera de la programación que llevó el Apolo a la Luna. 2014. Disponível em: https://verne.elpais.com/verne/2014/12/11/articulo/1418314336_993353.html. Arquivado em: https://web.archive.org/web/20141225145142/https://verne.elpais.com/verne/2014/12/11/articulo/1418314336_993353.html.
NAUR, P.; RANDELL, B. (EDS.). Software Engineering: Report on a conference sponsored by the NATO SCIENCE COMMITTEE. [s.l.] Brussels: Scientific Affairs Division, NATO, 1969.
PLATO. Republic. Translated by G.M.A. Grube, revised by C.D.C. Reeve. Indianapolis: Hackett Publishing Company, 1992.
TEDRE, M.; SUTINEN, E. Three traditions of computing: what educators should know. Computer Science Education, v. 18, n. 3, p. 153–170, set. 2008.
THOMAS, A. S.; MAURER, A. A.; PONTIFICAL INSTITUTE OF MEDIAEVAL STUDIES. The division and methods of the sciences : questions V and VI of his Commentary on the De Trinitate of Boethius. Toronto: Pontifical Institute Of Mediaeval Studies, 1986.
E.W. Dijkstra Archive: On the cruelty of really teaching computing science (EWD 1036). Disponível em: https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html. Arquivado em: https://web.archive.org/web/20240330000400/https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html.
HARTMANIS, J. Some observations about the nature of computer science. In: SHYAMASUNDAR, R.K. (Ed.). Lecture notes in computer science, Vol. 761. Berlin: Springer, 1993. p. 1–12.