Na Lean Manufacturing (termo traduzido como "produção enxuta" ou "fabricação otimizada"), o significado de estoque é bem claro: é o material adicional, o material sendo usado no momento, ou o material que está pronto para ser usado na próxima parte do trabalho. A mentalidade Lean enfatiza a redução do estoque, porque sempre há custos associados à sua manutenção. No desenvolvimento de software, os requisitos são frequentemente tratados como estoque. Mas e o código?
Sobre isso, Michael Feathers diz:
Se você gasta muito tempo elaborando requisitos para funcionalidades que não vai implementar de imediato, seu processo não é simples o suficiente. Isso é verdade, mas a dura realidade é que temos algo muito mais tangível que podemos tratar como se fosse estoque: o nosso código.
Ainda segundo Feathers, na produção enxuta os produtos são feitos um a um. Pode-se ganhar eficiência simplificando a forma como as peças são manipuladas no processo. Mas quando se trata de software, as coisas são diferentes. Em software, há equipes trabalhando sempre na mesma peça, e esta praticamente só fica pronta quando começa a ser usada. Portanto, o código é um estoque vivo que nos acompanha e que precisa ser minimizado.
No desenvolvimento de software, estamos essencialmente trabalhando no mesmo carro ou produto, não raro durante anos. Estamos envolvidos na mesma base de código, no mesmo problema. Não podemos esperar que um modelo de produção baseado na independência das peças funcione adequadamente quando trabalhamos continuamente com uma coisa só (o código), que se desgasta com o tempo e precisa de atenção constante. Para mim, o código é estoque e tem um considerável custo de propriedade. É saudável pensar em formas de minimizá-lo.
De forma similar, Ori Pekelman sugere que código é mais uma responsabilidade ou um risco do que um ativo. As equipes, segundo ele, têm que escrever código para construir um produto e ganhar dinheiro. Mas depois deveriam encontrar maneiras de reduzir o código o máximo possível, para manter os custos baixos. Para Pekelman,
Quanto mais código se tem, mais custoso será adicionar coisas novas. E a má notícia é que tudo que se adicionar ao código existente aumentará o problema, tornando acréscimos posteriores ainda mais custosos. Mas a utilidade marginal negativa do código existente não é imutável: quanto melhor estruturado estiver, quanto mais testes unitários existirem, quanto mais forem usados bancos de dados sem esquema ou com esquemas flexíveis, menos custoso o novo código será.
No livro The Art of Readable Code ("A Arte do Código Legível", sem tradução em português) de Boswell e Foucher, os autores enfatizam a importância de se ter bases de código enxutas, indicando que a melhor forma de lidar com um sistema em produção é mantendo seu código o mais resumido e leve possível. Alguns dos caminhos sugeridos são:
- Criar o máximo possível de utilitários de uso geral;
- Remover código ou funcionalidades não utilizadas;
- Modularizar projetos em subprojetos independentes;
- Ter familiaridade com bibliotecas que podem ser usadas;
- Ter sempre consciência do tamanho do código e mantê-lo leve e ágil.
Kevlin Henney destaca que há grande necessidade de excluir código e torná-lo o mais leve possível, em seu guia prático para escrever menos código.
Portanto, há fortes motivos para manter seu código leve e ágil, como Feathers resumiu:
Considero que o futuro pertence às organizações que aprendem a estrategicamente a apagar código. O custo de manutenção de estoques é maior do que se pensa e as empresas que percebem isso têm vantagens competitivas.