Se você é aquele tipo de programador que pensa que o seu código está pronto quando você faz o commit para o repositório, sinto lhe dizer mas você está errado.

Eu sei disso porque eu também já pensei dessa maneira. Por muitos anos eu pensei da seguinte forma: Eu sou programador, portanto meu papel é escrever código. Já que esse é meu papel, a partir do momento que eu entrego o código, significa que o meu trabalho está feito.

Existe um problema de premissa nessa lógica (torta) de pensamento. Seu papel como programador não é escrever código. Seu papel como programador é resolver problema.

Se levarmos ao pé da letra, um software não estará pronto nunca. A única constante no mundo é a mudança. O software, de uma maneira genérica, tem como objetivo facilitar processos do mundo real. Se o mundo está mudando a todo instante, o software deve, necessariamente, mudar também para continuar gerando valor.

Mas meu objetivo não é falar do software como uma forma abstrata. Eu quero descer um pouco mais o nível e falar sobre as funcionalidades que compõem um software. Mais especificamente sobre o código que compõe essa funcionalidade.

Quando a gente pode considerar que um código foi entregue?

Porque escrevemos código…

O software sempre nasce com o objetivo de resolver um problema da vida real. Ele é feito de humanos, para humanos.

A funcionalidade surge, geralmente, no momento em que o usuário de um software identifica um problema e entende que esse problema pode ser resolvido pelo software.

Vamos imaginar o cenário: Seu cliente tem um problema. Você conversa com o cliente, entende o problema dele. Feito isso, você imagina qual a melhor solução para isso. Com a solução mais ou menos desenhada na sua cabeça, você senta a bunda na cadeira e vai para a parte mais divertida, que é codar. No final do dia você fez algo super legal. Faz o commit para o repositório e termina de codar.

Seu código foi entregue? Para responder é simples, basta fazer outra pergunta: Neste exato momento, o cliente tem o problema dele resolvido? Não! Portanto, seu código ainda não está pronto.

Seu código só vai estar pronto no momento em que resolver o problema do seu cliente. Seu código só vai estar pronto no momento em que gerar valor ao seu cliente. 

E quando acontece isso? Quando ele vai para produção, seu cliente começa a utilizá-lo e então percebe que teve seu problema resolvido.

Ou seja: Código pronto é código em produção sendo usado.

Como entregar código que resolve problema?

O grande erro de todos nós programadores sempre é o mesmo: achar que sabemos o que o nosso cliente quer. Não, a gente não sabe. Nós, no máximo, temos hipóteses.

Para contornar este problema, a solução é entregar o código o mais rápido possível para que o cliente possa utilizar e entender se aquela solução resolve o problema dele ou não.

Com isso, nós estamos validando uma hipótese de solução.

Então, quanto mais rápido nós produzirmos código, mais rápido vamos entregar o código, certo? ERRADO!

O objetivo não é produzir código rápido, o objetivo é entregar o código rápido. Entregar esse código significa entregá-lo funcionando sem que o resto do sistema tenha sido afetado. Devemos resolver problemas, e não gerar mais problemas.

O software precisa ser sustentável. O código precisa ser sustentável. Para desenvolver código sustentável é preciso parar de pensar em quantidade e começar a pensar em qualidade. 

Escrever código com qualidade é mais demorado no curto prazo, porém nos poupa tempo (dinheiro) de manutenção no futuro. No longo prazo, temos menos desperdício de recursos.

Software sustentável é um software que tem a capacidade de reagir bem a mudanças. Para garantir isso, precisamos criar código, testar o código que criamos e garantir que este novo código funcione bem junto aos códigos antigos.