Princípio da falseabilidade em tecnologia: como tomar decisões mais assertivas

Na área de tecnologia, vivemos um momento de grande aceleração. Existem muitas tecnologias e muitas formas de se resolver problemas.

Em boa parte das vezes, é natural que tenhamos dificuldade em escolher a solução mais assertiva para cada problema em meio a tantas opções, além de verificar se a solução proposta realmente funciona como deveria.

Esse artigo tem como objetivo mostrar como o princípio da Falseabilidade pode ser usado para achar soluções mais assertivas que funcionam de fato. Vem comigo!

O princípio da falseabilidade

Sendo uma das bases do método científico moderno, este princípio é frequentemente sinônimo de testabilidade, ou seja, para validarmos uma hipótese qualquer, precisamos ter testes tangíveis/observáveis para tal.

Isso pode ser aplicado de diversas formas, por exemplo, se temos uma hipótese que a tecnologia X é melhor que a tecnologia Y em determinado cenário, a melhor forma de validar isso é criando experimentos e verificando qual tecnologia de fato atende as expectativas no contexto proposto.

Se não temos como testar uma hipótese, não estamos lidando com um método científico e é bastante possível que vamos chegar a soluções subótimas que não irão resolver o problema com eficiência.

Falseabilidade ou refutabilidade, é a propriedade de uma asserção, ideia, hipótese ou teoria poder ser mostrada falsa. Conceito importante na filosofia da ciência, foi proposto pelo filósofo austríaco Karl Popper na década de 1930, como solução para o chamado problema da indução.

Para uma asserção ser refutável ou falseável, é necessário que haja pelo menos um experimento ou observação factíveis que, fornecendo determinado resultado, implique a falsidade da asserção. Por exemplo, a asserção “todos os corvos são pretos” poderia ser falseada pela observação de um corvo vermelho.

(definição na wikipedia)

Revisão de código

Imagine o seguinte cenário: alguém envia uma correção de um bug pra revisão de código; o pull request é aceito e publicado em produção. Mas logo depois, alguém reporta que o bug continua acontecendo. O que deu errado aqui?

Revisão de código & qualidade em geral é um tema bastante extenso, mas é bem possível que deixamos de validar o princípio da falseabilidade nesse caso.

Explico: quando revisamos um pull request que corrige um bug, não basta apenas executar o fluxo e ver que o bug não acontece mais. É preciso antes de tudo fazer o bug acontecer (na branch main ou branch que não possui a correção) e só depois precisamos ver que o bug não acontece sob as mesmas condições.

Quando apenas executamos o “cenário feliz” do teste, podemos não acertar as condições para o bug acontecer, e com isso não estamos testando de fato. Por conta disso é tão importante primeiro ver o bug acontecer para só depois testar se de fato o bug não acontece mais.

Revisão de código é um assunto bastante extenso, por isso vou deixar mais duas referências pra aprofundar a leitura: How to review someone else’s code & My personal guide to code review

Escrevendo testes unitários

O ponto acima também pode acontecer nos testes unitários. Podemos escrever testes que executam com sucesso, mas na verdade não verificam se efetivamente a correção funciona.

Uma coisa que pode atrapalhar muito os testes é o excesso de mocks. Como não estamos de fato executando o código completo, isso pode gerar ruídos e não falhar quando deveria.

Uma receita simples pra usar a falseabilidade em testes unitários é seguir a metodologia TDD. Como primeiro nós vemos o teste falhar pra depois corrigir, já temos o princípio da falseabilidade embutido 😎

Se não for possível seguir o TDD por qualquer motivo, também temos uma forma mais manual de usar a falseabilidade:

Imagine que temos um teste para uma correção de bug. Para verificar se a correção de bug passa do princípio da falseabilidade, basta desfazer o código de correção e executar o teste. O teste deverá quebrar nesse caso.

Se não quebrar, é possível que o cenário de teste/dados iniciais não fazem o bug acontecer, e aí precisamos voltar um passo e entender quais são as condições pro bug ser replicado.

Escolhendo uma stack de tecnologia

“Qual linguagem é melhor? Qual framework? Qual cloud?” São todas ótimas questões, com pessoas muito energéticas dispostas a defender cada solução.

Mas a boa notícia é que podemos usar o método científico para tomar boas decisões baseadas em dados, observação e testes, ao invés de hype.

Um exemplo: Como escolher entre GO e Python?

Resposta: Depende!

Precisamos definir qual será o contexto de aplicação da linguagem e com isso definir algumas condições de teste pra verificar qual solução resolve melhor o problema.

Por exemplo, se precisamos fazer uma aplicação de manipulação de dados, podemos montar uma prova de conceito simples comparando como cada linguagem resolve o mesmo problema proposto.

Com isso, se o cenário mudar, os critérios de teste também mudariam e possivelmente a conclusão final.

Em resumo, a melhor linguagem é sempre aquela que resolve com elegância os problemas do contexto proposto.

Inspiração & Referências:

Venho usando esse princípio no dia a dia faz um bom tempo, mas foi só recentemente que liguei uma coisa à outra durante a leitura do livro The Great Mental Models Volume 1: General Thinking Concepts. Tem também esse artigo (Falsification: How to Destroy Incorrect Ideas) no blog do autor do livro ;)

Além disso, esse vídeo do Átila Iamarino - O que te faz mudar de ideia? - acaba usando de forma implícita o mesmo conceito, de uma forma mais ampla.

Outras referências pra continuar a leitura:
- https://whatis.techtarget.com/definition/falsifiability
- https://pt.wikipedia.org/wiki/M%C3%A9todo_cient%C3%ADfico
- https://pt.wikipedia.org/wiki/Falseabilidade