Teoria da Janela Quebrada
EDIT: Este post foi criado dia 22/10/2009 e alterado dia 31/01/2010.
A teoria da janela quebrada foi formulada em Nova Iorque após algumas experiências feitas em bairros nobres da cidade. Em um dos testes realizados, um carro foi deixado parado em uma rua e durante uma semana inteira ninguém tocou no carro. Os responsáveis pela experiência então quebraram propositalmente uma das janelas do carro e deixaram por mais uma semana exatamente no mesmo lugar. Qual foi o resultado? O carro foi completamente destruído, janelas quebradas, peças roubadas dentre outras degradações.
Esta teoria é aplicada em uma Política de Tolerância Zero nos estados unidos onde cada crime, por mais pequeno que seja, passa por uma punição. Uma simples pixação já é suficiente para que o delinquente seja levado pela polícia e a parede pixada é rapidamente limpada. Com o tempo percebeu-se que havia diminuido a quantidade de pixação já que era sabido que havia punição e que a polícia estava sempre de olho. Esta teoria foi assunto de um livro chamado Fixing Broken Windows: Restoring Order And Reducing Crime In Our Communities sobre a sua utilização no combate à crimanilidade.
Vejo que isto também acontece bastante com os aparelhos eletrônicos. Nos primeiros dias após a compra está tudo em perfeito estado, todo o cuidado é pouco para não danificá-lo. Todo esse cuidado acaba quando ele cai pela primeira vez. Na hora da até um aperto no coração, porém, a partir da segunda ou terceira queda ninguém se importa mais.
O que isso tem a ver com desenvolvimento de software? Tudo. O primeiro dia de um projeto é o paraíso, existem poucas classes no sistema, complexidade do código está baixa e o prazo de entrega está bem longe. O tempo vai passando, a complexidade aumentando e o prazo apertando, a tendência é que a qualidade do código baixe, pois você precisa se preocupar mais com a entrega do que com o design do código. Você adquire o famoso Technical Debt. Nesses momentos surge frases como: “Cara, faz assim mesmo, depois da entrega do produto eu te dou mais uma semana para arrumar isso”. Esse dia nunca chega.
Tendo um produto com design ruim ninguém vai se importar de fazer uma manutenção e continuar errando, o que vai contra a regra dos escoteiros, que diz: “Deixe o acampamento mais limpo do que você encontrou” e também se aplica à software.
O que fazer nestes casos? Refactore, refatore e refatore um pouco mais. Deixe o código o mais limpo possível. Se as donas de casa limpam TODA a casa uma vez (ou duas) por semana, porque também não fazemos o mesmo com nosso software?
E ai, você atua em um projeto com janelas quebradas? Cuidado.
Muito bom saber desta teoria e concordo com o seu ponto de vista no artigo.