por Joel Spolsky
Quinta-feira, 6 de abril, 2000
tradução Edison Henrique Andreassy
O Netscape 6.0 está finalmente entrando em seu primeiro beta público. Nunca houve uma versão 5.0. O último grande lançamento, o da versão 4.0, foi feito há quase três anos. Três anos é um tempo muito longo no mundo da Internet. Durante esse tempo, a Netscape acomodou-se, impotentemente, enquanto sua participação no mercado despencava.
É um pouco deselegante da minha parte criticá-los por esperar tanto tempo entre essas liberações. Afinal, eles não fizeram isso de propósito, não é?
Bem, sim. Eles fizeram. Eles fizeram isso, tomando uma única e pior decisão estratégica que qualquer empresa de software pode tomar:
Eles decidiram reescrever o código do zero.
A Netscape não foi a primeira empresa a cometer esse erro. A Borland também cometeu o mesmo erro quando comprou o Arago e tentou fazê-lo um dBase para Windows, um projeto condenado que levou tanto tempo para ser feito que o Microsoft Access comeu a sua fatia do bolo, em seguida, eles fizeram isso novamente ao reescrever o Quattro Pro a partir do zero e depois surpreender as pessoas com tão poucas coisas que ele tinha a oferecer. A Microsoft quase cometeu o mesmo erro, tentando reescrever o Word a partir do zero em um projeto chamado Pyramid que depois foi cancelado, jogado fora, e varrido para debaixo do tapete. Sorte da Microsoft que eles nunca pararam de trabalhar no código antigo, assim pelo menos eles tiveram algo para liberar, tornando-se apenas um desastre financeiro, e não estratégico.
Nós somos programadores. Programadores são, em seus corações, arquitetos e a primeira coisa que querem fazer quando chegam em um lugar para trabalhar é aplanar tudo e construir algo grandioso. Nós não ficamos entusiasmados com evoluções incrementais: consertando, melhorando, plantando canteiros de flores.
Há uma razão sutil para que os programadores sempre querem jogar fora um código e começar do zero. A razão é que eles acham que o código antigo é uma bagunça. E aqui é a observação interessante: eles estão provavelmente errados. A razão pela qual eles acham que um código antigo é uma bagunça é por causa de uma lei cardeal, fundamental da programação:
É mais difícil ler um código do que escrevê-lo.
É por isso que a reutilização de código é tão difícil. É por isso que todos em sua equipe tem uma função diferente para dividir strings em array de strings. Eles escrevem as suas próprias funções porque é mais fácil e mais divertido faze-lo do que descobrir como funções pré-existentes funcionam.
Como corolário desse axioma, você pode pedir a quase qualquer programador hoje sobre o código que eles estão trabalhando. "É uma grande bagunça cabeluda", eles vão te dizer. "Eu gostaria de nada mais do que jogá-lo fora e começar de novo."
Por que é uma bagunça?
"Bem", eles dizem, "olhe esta função. Ela tem duas páginas! Nada disso pertence aqui e eu não sei o que metade destas chamadas de API estão fazendo."
Antes da nova planilha da Borland para Windows ser liberada, Philippe Kahn, o cheio de graça fundador da Borland, foi citado inúmeras vezes na imprensa comentando sobre como o Quattro Pro seria muito melhor do que o Microsoft Excel, porque foi escrito a partir do zero. É um código fonte novinho! Como se o código-fonte enferrujasse.
A ideia de que um novo código fonte é melhor do que um velho é um absurdo. O código antigo foi usado. Ele foi testado. Muitos erros foram encontrados, e eles foram corrigidos. Não há nada de errado com ele. Ele não adquire os erros apenas ficando parado no disco rígido. Au contraire, baby! Por acaso software é como um carro que se oxida apenas ficando parado na garagem? Por acaso software é como um ursinho de pelúcia que fica horrendo quando não vem feito de um material novo?
Voltando a função de duas páginas. Sim, eu sei, é apenas uma função simples para exibir uma janela, mas tem crescido pelos e outras coisas sobre ela e ninguém sabe porquê. Bem, eu vou te dizer o porquê: esses são correções de bugs. Uma delas corrige um bug que a Nancy teve quando tentou instalar a coisa em um computador que não tem Internet Explorer. Outro que corrige bug que ocorre em condições de pouca memória. Mais umas correções de bugs que ocorreram quando o arquivo está em uma unidade de disco e o usuário puxa o disco fora no meio do processamento. E essa chamada a LoadLibrary que é feia, mas faz bem o trabalho versões antigas do Windows.
Cada um desses erros levaram semanas de uso no mundo real antes de serem encontrados. O programador pode ter passado um par de dias tentando reproduzir o bug no laboratório e corrigi-lo. E se é como um grande parte dos bugs, a correção pode ser uma linha de código, ou pode até mesmo ser um par de caracteres, mas uma boa quantidade de trabalho foi desprendida para ajustar esses dois caracteres.
Quando você joga fora um código e começa do zero, você está jogando fora todo esse conhecimento. Todas essas correções coletadas. Anos de trabalho de programação.
Você está jogando fora a sua liderança de mercado. Você está dando um presente de dois ou três anos a seus concorrentes, e acredite em mim, isto é um longo período de tempo em termos de software.
Você está se colocando em uma posição extremamente perigosa, onde você estará liberando uma versão antiga do código por vários anos, e ficando completamente incapaz de fazer quaisquer mudanças estratégicas ou reagir às novas características que o mercado exige, só porque você não tem um código pronto para liberar. Você poderá ficar fora do mercado durante esse período.
Você está desperdiçando uma quantidade imensurável de dinheiro só para reescrever um código que já existe.
Existe uma alternativa? O consenso parece ser de que a antiga base de código do Netscape era muito ruim. Bem, pode até ter sido ruim, mas, você sabe o quê? Funcionou bem pra caramba em uma enorme quantidade de computadores e sistemas no mundo real.
Quando os programadores dizem que o seu código é uma verdadeira bagunça (como sempre dizem), existem três tipos de coisas que podem realmente estar erradas nele.
Em primeiro lugar, há problemas arquitetônicos. O código não foi criado corretamente. No código de rede está aparecendo caixas de diálogo a partir do meio do nada, isso deveria ter sido tratado no código da UI. Estes problemas podem ser resolvidos, um de cada vez, com movimentos cuidadosos, com refatorações, com alterações de interfaces. Elas podem ser feitas por um programador trabalhando com cuidado e que faça as gravações em lotes isolados, de modo que ninguém mais seja interrompido. Mesmo grandes mudanças arquitetônicas podem ser feitos sem jogar fora o código. Sobre o projeto Juno, passamos vários meses rearquitetando em apenas um ponto, movendo coisas para lá e para cá, limpando, criando classes base que faziam sentido, criando interfaces claras entre os módulos. Mas fizemos com cuidado, com a nossa base de código existente, e nós não introduzimos novos bugs ou jogamos fora um código em produção.
Uma segunda razão programadores pensarem que o código é uma confusão é que ele é ineficiente. Haviam rumores de que o código de renderização do Netscape era lento. Mas isso só afeta uma pequena parte do projeto, que você pode otimizar ou até mesmo reescrever. Você não tem que reescrever a coisa toda. Ao otimizar a velocidade, 1% do trabalho você recebe 99% do impacto.
Em terceiro lugar, o código pode ser ridiculamente feio. Um projeto que eu trabalhei realmente tinha um tipo de dados chamado FuckedString. Outro projeto tinha começado com a convenção de que as variáveis deveriam iniciar com "_", só que mais tarde trocou para o padrão "m_". Assim, metade das coisas iniciavam com "_" e outra metade com "m_", que tosco! Francamente, este é o tipo de coisa que você resolver em cinco minutos com uma macro no Emacs, e não por começar do zero.
É importante lembrar que quando você começa do zero, não há absolutamente razão alguma para acreditar que você vai fazer um trabalho melhor do que você fez pela primeira vez. Primeiro de tudo, você provavelmente não tem sequer a mesma equipe de programação que trabalhou em uma versão, então você realmente não tem "mais experiência". Você só está caminhando para cometer os mesmo erros novamente, e agregar mais alguns novos que não estavam na versão original.
O velho mantra construir e jogar fora é perigoso quando usado em aplicações comerciais de grande porte. Se você estiver escrevendo código experimentalmente, você pode querer se desfazer da função que você escreveu na semana passada enquanto você pensa em um algoritmo melhor. Isso é bom. Você pode querer refazer uma classe para torná-la mais fácil de usar. Isso é bom, também. Mas, jogar fora todo um sistema é uma loucura perigosa, e se a Netscape realmente tivesse alguma supervisão de um adulto com experiência na indústria de software, eles poderiam não ter atirado no próprio pé de forma tão ruim.