Software não é ciência

Vejo com frequência a entrega de trabalhos em conferências e propostas de teses de PhD que centram totalmente em um pedaço de um software que alguém desenvolveu. O resumo normalmente começa como algo assim:

Nós desenvolvemos METAFOO, um simulador de sensor de rede que captura precisamente o nível de consumo de energia do equipamento (hardware). METAFOO tem um design modular que alcança alta flexibilidade ao permitir que novos modelos de componentes sejam conectados à simulação. METAFOO também incorpora o ambiente Java baseado em GUI para visualizar os resultados da simulação, além de plugins para MATLAB, R, e Gnuplot para analisar execuções de simulações…

Você entende a ideia. Mais frequentemente do que deveria, os trabalhos são como descrições técnicas do software, com diagramas de blocos complexos, vários quadros e setas, e uma narrativa detalhada de cada parte do sistema, em qual linguagem está implementado, quantas linhas de códigos possui etc. Os autores desses tipos de trabalhos realmente acreditam que isso fará uma boa apresentação em conferências.

Apesar de isso tudo poder ser interessante para alguém que planeja usar o software ou trabalhar em cima dele, isso não é o objetivo de uma publicação científica ou de uma dissertação de PhD. Muito constantemente, pesquisadores – especialmente aqueles em sistemas – parecem confundir o questionamento científico com o artefato de software que constroem para explorar esse questionamento. Eles ficam presos à ideia de construir um lindo pedaço de software, esquecendo que o objetivo era fazer ciência.

Quando eu vejo uma submissão de um trabalho assim, eu começo a lê-lo na esperança de que exista uma grande compreensão ou uma faísca de inspiração no design do sistema. Normalmente, não existe. O trabalho se envolve tanto em descrever o artefato que se esquece de estabelecer as contribuições científicas que foram feitas para desenvolver o software. Esses trabalhos não tendem a participar de grandes conferências, e eles não têm boa fundamentação para uma dissertação PhD.

Em pesquisas de sistemas de computação, existem dois tipos de software que as pessoas desenvolvem. A primeira categoria compreende ferramentas usadas para suportar outras pesquisas. Isso inclui coisas como bancos de teste, simuladores, e assim por diante. Isso é geralmente um ótimo, e de valor inestimável, software, mas não o objetivo da pesquisa propriamente dita. Inúmeros pesquisadores têm usado ns2, Emulab, Planetlab etc para fazer o trabalho deles e, sem esse investimento, a comunidade não consegue prosseguir. Mas, muitas vezes, os estudantes acham que construir ferramentas úteis equivale a fazer pesquisa. Não equivale.

O segundo, e mais importante, tipo de software é um protótipo processual para demonstrar uma ideia. No entanto, o objetivo do trabalho é a ideia que ele representa, não o software em si. Bons exemplos disso incluem coisas como Exokernel e Barrelfish. Esses sistemas demonstram um lindo conjunto de conceitos (extensibilidade do sistema operacional e transmissão de mensagens em processadores com múltiplos núcleos, respectivamente), mas ninguém de fato usou esses pedaços de software para nada além de obtenção de gráficos para um trabalho, ou uma demonstração bonitinha em uma conferência.

Existem raras exceções de “pesquisa” de software que avançaram além da fase de prototipagem. TinyOS e Click são dois bons exemplos. Mas isso é a exceção, não a regra. Geralmente, eu não aconselharia estudantes de graduação a gastar muita energia em divulgar seus protótipos de pesquisa.
Provavelmente ninguém irá usar seus códigos, e o tempo que você gasta transformando o protótipo em um sistema real é um tempo melhor gasto se você buscar novas ideias e escrever ótimos trabalhos. Se acontecer de seu software não incorporar nenhuma nova ideia radical, e, ao contrário, você estiver gastando seu tempo adicionando um GUI ou escrevendo documentação, você provavelmente está gastando seu tempo com a coisa errada.

Então, como você escreve um trabalho sobre um pedaço de software? Três recomendações:

1. Coloque as contribuições científicas primeiro. Faça o trabalho sobre as contribuições chaves que você está fazendo na área. Discorra sobre elas cuidadosamente, na primeira página do trabalho. Tenha certeza de que elas são realmente contribuições do núcleo científico, não algo como “nossa primeira contribuição é que nós desenvolvemos METAFOO”. Um exemplo melhor seria “Demonstramos que a partir de uma decomposição cuidadosa do ciclo de precisão da simulação da lógica a partir da poderosa modelagem, somos capazes de alcançar muito mais precisão ao escalar um grande número de nós”. Seu software será o veículo que você usará para provar seu objetivo.
2. Desassocie as novas ideias do próprio software. Alguém poderá aparecer e pegar suas ótimas ideias e aplicá-las em outro sistema de software ou em um problema completamente diferente. A ideia principal que você está promovendo não deve estar ligada a um complexo código que você teve que escrever para mostrar como ela funciona na prática. Usando Click como um exemplo, seu design modular já foi reciclado em vários, vários outros sistemas de softwares (incluindo a minha própria tese de PhD).
3. Pense a respeito de quem irá se importar com esse trabalho 20 anos mais tarde. Se seu trabalho é totalmente sobre algum pequeno aspecto que você está adicionando em alguma base de código, a chance é que ninguém irá se importar. Tente apresentar as questões duradouras sobre seu trabalho e foque nisso.

?
Texto original disponível em http://matt-welsh.blogspot.com/2011/11/software-is-not-science.html