Eu reescrevo este artigo de tempos em tempos. O mais interessante de tudo isso é que a história nunca fica ultrapassada.
Este artigo inicia com uma história de um browser que era muito popular no início da internet comercial: o Netscape. Como um software que dominava o mercado saiu de uma prateleira para o ostracismo e a falência. A grande sacada de todo o processo é que há uma equipe da Netscape que habita em cada um de nós. Por sorte, todos temem os boletos que vencem no final do mês! É a contra-partida para que não façamos mais nenhuma besteira.
Diz a lenda que um dia a Netscape caiu na besteira de reescrever o código de um browser popular na época do zero. E isso levou a empresa à falência. Por que reescrever um código do zero pode ser tão ruim assim? Bom… vamos a algumas variáveis. Temos tecnologia atual melhor do que eles tinham no passado. Os processos hoje são mais eficientes. Mas no passado a parte de organização de código não era uma coisa muito valorizada. Não era incomum o código ficar “macarrônico”.
No próprio artigo original o autor comenta um comportamento típico de um programador: a preguiça original. Por definição, é muito mais fácil escrever um código do que ler e interpretar. Essa característica faz com que os programadores desqualifiquem o trabalho dos outros e ponham o quinhão deles em jogo: “reescrevemos e supostamente resolvemos o problema”. Mas… não é bem assim. As características de um projeto grande como era o Browser da Netscape faz com que essa realidade seja um pouco diferente.
Muito do suporte que o sistema operacional oferece hoje a diversos tipos de máquinas não existia no passado. Então, algum programador, pode ter trabalhado num bug que ocorria somente numa máquina 486 (se você não sabe o que é isso pesquise na internet) com 32MB de RAM rodando windows 95 sem uma atualização X. Os sistemas operacionais evoluíram a ponto de tirar uma característica como essa do programador, mas não tinham esse suporte no passado. Ou seja, numa versão mais nova, provavelmente o software já vinha com esse bug. Existiu um movimento de organização e convergência para que os sistemas operacionais suportassem cada vez mais hardware sem muitos problemas. Porém, no passado não era assim. Hoje, dependendo do programa, não é necessário pensar nisto… mas é necessário frisar que isso é uma evolução.
Outro ponto, que eu acredito não ter sido abordado com muita profundidade no artigo original é a diferença entre o que as pessoas acreditam que seja e o que realmente é. Se você faz algum tipo de planejamento sabe exatamente o que eu estou falando. O que nós não sabemos é muito mais relevante do que aquilo que é do nosso conhecimento atual. Isso porque quando começamos realmente um projeto é que os reais problemas aparecem. Emuladores não simulam a aleatoriedade. Jogo é jogo, treino é treino. O simples fato de fazer um programador ganhar controle do problema faz com ele não despreze tanto o trabalho de quem ralou para construir as coisas e passe a entender melhor a lógica do negócio. Coisas simples como regras de clean code podem fazer parte do refatoramento de um projeto da forma menos indolor possível. Acredito que isso é melhor do que ficar sem um projeto!
Não precisamos ser tão inteligentes assim para entender onde podem estar as causas do problema. Óbvio que um código ruim pode ser doloroso, mas reescrever um código não é garantia de qualidade. Qualquer rotatividade de programadores no projeto ferra com isso. Ai o ciclo recomeça… E isso vira o mito de Sísifo. Sísifo foi condenado a rolar uma pedra morro acima no monte Olimpo e toda vez que ele chega perto do cume a pedra escorrega da sua mão e volta a base. Você pode ir ganhando controle aos poucos e pode fazer isso ser melhor a cada dia.
A péssima decisão da Netscape não é única, mas foi emblemática porque eles possuíam um software extramente popular que todos gostavam. E infelizmente, foi engolido por um erro que atualmente consideramos primário. Sempre que for tomar uma decisão lembre-se de uma coisa: o que você não sabe é sempre muito mais relevante do que o que sabe.