Menos software

Mantenha seu código o mais simples possível

Você poderia pensar que o dobro de código tornaria seu software apenas duas vezes mais complexo. Mas, na verdade, cada vez que você aumenta a quantidade de código, seu software se torna exponencialmente mais complicado. Cada pequena adição, cada mudança, cada interdependência e cada preferência tem um efeito cascata. Continue adicionando código sem critério e, antes que perceba, você terá criado a temida Grande Bola de Lama.

A maneira de combater essa complexidade é com menos software. Menos software significa menos funcionalidades, menos código, menos desperdício.

A chave é reformular qualquer problema difícil que exija muito software em um problema simples que exige muito menos. Talvez você não esteja resolvendo exatamente o mesmo problema, mas tudo bem. Resolver 80% do problema original com 20% do esforço é uma grande vitória. O problema original quase nunca é tão grave que valha a pena cinco vezes o esforço para resolvê-lo.

Menos software significa guardar a bola de cristal. Em vez de tentar prever problemas futuros, você lida apenas com os problemas de hoje. Por quê? Os medos que você tem sobre o amanhã muitas vezes nunca se concretizam. Não se sobrecarregue tentando resolver esses problemas fantasmas.

Desde o início, projetamos nossos produtos em torno do conceito de menos software. Sempre que possível, dividimos problemas difíceis em fáceis. Descobrimos que soluções para problemas fáceis não são apenas mais fáceis de implementar e suportar, elas são mais fáceis de entender e de usar. Isso faz parte de como nos diferenciamos dos concorrentes; em vez de tentar construir produtos que fazem mais, construímos produtos que fazem menos.

As funcionalidades que você escolhe incluir ou omitir também têm muito a ver com menos software. Não tenha medo de dizer não a pedidos de funcionalidades que são difíceis de fazer. A menos que sejam absolutamente essenciais, economize tempo/esforço/confusão deixando-os de fora.

Desacelere também. Não tome uma ação sobre uma ideia por uma semana e veja se ela ainda parece uma ótima ideia depois que o entusiasmo inicial passar. O tempo extra para maturar a ideia muitas vezes ajudará seu cérebro a encontrar uma solução mais fácil.

Encoraje os programadores a fazerem contrapropostas.

Você quer ouvir: "Do jeito que você sugeriu vai levar 12 horas. Mas tem um jeito que eu posso fazer que vai levar apenas uma hora. Não vai fazer x mas vai fazer y." Deixe o software contra-argumentar. Diga aos programadores para lutarem pelo que eles acham que é o melhor caminho.

Além disso, busque desvios para evitar escrever mais software. Você pode mudar o texto na tela para que sugira um caminho alternativo aos clientes que não exija uma mudança no modelo de software? Por exemplo, você pode sugerir que as pessoas façam upload de imagens de um tamanho específico em vez de fazer a manipulação de imagem no lado do servidor?

Para cada funcionalidade que entrar no seu aplicativo, pergunte-se: Há uma maneira de adicioná-la que não exigirá tanto software? Escreva apenas o código de que você precisa e nada mais. Seu aplicativo será mais enxuto e saudável como resultado.

Não há CÓDIGO mais flexível do que NENHUM código

O "segredo" para um bom design de software não estava em saber o que colocar no código; estava em saber o que DEIXAR DE FORA! Estava em reconhecer onde estavam os pontos difíceis e os pontos fáceis, e saber onde deixar espaço/sala em vez de tentar enfiar mais design.

—Brad Appleton, engenheiro de software (de Não Há CÓDIGO mais flexível do que NENHUM Código!)

A complexidade não escala linearmente com o tamanho

A regra mais importante da engenharia de software é também a menos conhecida: A complexidade não escala linearmente com o tamanho...Um programa de 2000 linhas requer mais do que o dobro do tempo de desenvolvimento de um com metade do tamanho.

—The Ganssle Group (de Mantenha Pequeno)