The Wayback Machine - https://web.archive.org/web/20081121123701/http://www.visibleworkings.com/archeology/Kerth.html

Por Norman L. Kerth

nkerth@acm.org

Meu dicionário definiu a palavra arqueologia como

A recuperação sistemática e o estudo de evidências materiais, como sepulturas, edifícios, ferramentas e cerâmicas, remanescentes da vida humana e da cultura passadas.

Essa definição sugere que há mais no conceito de arqueologia de software do que apenas a rapidez com que um desenvolvedor pode entender um pedaço de um grande sistema que ele tem que reparar. Concordo que o rápido entendimento de um grande sistema de software tem aplicação comercial imediata. Dito isso, ressalto que a rápida compreensão para fins de modificação é apenas uma pequena parte das riquezas totais que podem advir do estudo cuidadoso de um antigo monumento da antiguidade.

Por exemplo, em Using Patterns to Improve Our Architectural Vision, os autores sugerem que a arqueologia de software é a base para uma nova abordagem à arquitetura de software, construída sobre o estudo das obras-primas dos grandes arquitetos de software do nosso campo. Eles pedem que as invenções e descobertas feitas pelos pioneiros em nosso campo sejam capturadas em forma de linguagem padrão para a ampla distribuição e apreciação dos praticantes modernos.

Mas a arqueologia de software não se preocupa apenas com a arquitetura de longa duração. A definição de arqueologia do meu dicionário também nos direciona para as ferramentas, linguagens e bibliotecas utilizadas; relatórios de bugs; atividades de gerenciamento de configuração; cronograma e histórico orçamentário; e assim por diante, com o objetivo de não apenas entender o artefato, mas através do artefato passamos a entender a vida e a cultura humanas. Em tal estudo, podemos descobrir o valor de práticas, procedimentos, metodologias e afins de desenvolvimento. Podemos ver a ascensão e queda de certas disciplinas. Tais estudos podem levar a uma prática moderna mais madura e fundamentada de nossa profissão. Também podemos aprender a evitar práticas que mostram uma história de problemas de longo prazo.

Por isso, faço as seguintes perguntas:

  • O que mais pode ser aprendido com o estudo arqueológico cuidadoso de um sistema de software?

  • Que sistemas são dignos de estudo disciplinado?

Como determinar quais sistemas merecem ser estudados? Todo sistema que precisa de aprimoramento é digno de um estudo arqueológico? Assim como a maioria dos edifícios na Península de Yucatán tem pouco valor de pesquisa, muitos sistemas de software têm pouco a nos ensinar. Mas e as obras de nossos grandes mestres. Suponhamos que pudéssemos encontrar o código para o sistema operacional THE de Dijkstra, seria digno de estudo? Acho que sim. Que tal o sistema operacional e compilador da Wirth’s Lillith Machine? Eu pessoalmente sei que há um grande valor em gastar tempo estudando esse código. Infelizmente, na época, eu não sabia como documentar o que aprendi, então, embora seja um grande aprendizado para mim, perdi a oportunidade de compartilhar o que descobri.

  • Qual é a disciplina de estudar um tesouro de software?

Quando leio a National Geographic, ou assisto ao programa de televisão Nova, vejo arqueólogos de campo trabalhando. Eles isolam um local, desenvolvem uma grade e se preparam para registrar meticulosamente suas atividades de pesquisa, bem como suas descobertas. Eles procedem no que eu chamaria de um ritmo terrivelmente lento, porque querem ter certeza de que não destroem evidências que possam interessar a futuros pesquisadores. Esta disciplina foi desenvolvida ao longo de mais de 100 anos. Os primeiros arqueólogos cometeram muitos erros e são lembrados na história não apenas por suas descobertas, mas também por seus erros. Como devemos estudar uma grande obra da antiguidade do software?

  • Qual é a ética que um arqueólogo de software deve subscrever?

Se estamos estudando um sistema de software, financiado pelo objetivo de melhoria, podemos também estar procurando descobrir e preservar as riquezas que estão contidas nele, incluindo a compreensão de como o sistema surgiu? Se sim, qual seria o impacto dessa refatoração nesse tesouro? As lições culturais a serem aprendidas, provavelmente serão perdidas, como um programador com uma perspectiva orientada a objetos trabalha em código criado por mestres do Lambda Calculus? Cometemos os erros cometidos pelos arqueólogos quando tentam escorar uma ruína de Anastasia com concreto, e lá perdemos quaisquer descobertas que pudessem ter sido possíveis, mesmo que as ruínas caíssem no chão?

Também me preocupa que os autores do software original sejam respeitados pelo que sabiam na época, dadas as ferramentas que tinham disponíveis na época, e assim por diante. Erramos nossos antepassados julgando-os através de conhecimentos, práticas e crenças modernas. É fácil rir de um programador FORTRAN usando GLOBAL COMMON extensivamente, até que você entenda as alternativas que ela tinha disponíveis durante essa fase do desenvolvimento do nosso campo.

  • Como documentar as descobertas arqueológicas de tal forma que tenham valor a longo prazo?

Uma linguagem padrão é realmente a melhor abordagem? Tenho certeza que existem outras formas com vantagens também. A UML tem alguma utilidade, uma vez que foi projetada para expressar ideias de design de uma forma que se assemelha ao pensamento moderno.

  • Como mudar nosso campo para que a prática da arqueologia de software seja um tema de pesquisa legítimo, abraçado pela academia e onde as agências de fomento estejam dispostas a aceitar propostas de subsídios?

Isso me leva à minha última pergunta:

  • Existe uma diferença entre o estudo de um grande sistema com o propósito de aprimoramento e o estudo de artefatos de software com o propósito de aprender sobre a história de nosso campo para nos ajudar a entender nosso presente e nosso futuro?

Deveriam ter sido duas oficinas separadas?

Using Patterns to Improve Our Architectural Vision, Norman L. Kerth e Ward Cunningham, IEEE Software, Vol. 14, No. 1, Janeiro/Fevereiro, 1997, pp. 53 - 59.

Artigo Original