É lixo? Então jogue fora!

Nem sempre é uma boa idéia continuar dando manutenção em uma pilha de código antiga apenas porque ela "está funcionando" ou porque ela foi escrita há muito tempo. Devemos ser capazes de entender que as vezes é mais fácil e até mesmo maia barato escrever um produto novo do que continuar dando manuteção numa macarronada que quase ninguém entende.

por Maurício Linhares de Aragão Junior

Você já parou para pensar na quantidade de entulho que nós juntamos na nossa casa e no trabalho?

Quem mora em apartamento, costuma não juntar tanta tralha, mas quem mora em casa, sempre tem aquele quartinho onde coloca aquelas coisas que você não usa mais, mas também não tem coragem de jogar fora.

Esse "lixo" costuma ocupar espaço, dar trabalho pra limpar e ainda pode juntar insetos e outros tipos de animais indesejáveis, como ratos. Por que nós simplesmente não jogamos tudo fora? Porque toda aquela tralha um dia foi útil ou ainda tem algum valor sentimental.

Quem não tem um daqueles livros antigos do ginásio, boletins de escola, aquele bilhetinho de um(a) namorada(o) ou aquele vídeo-game de 8 bits que nem liga mais. Você nem olha pra essas coisas, mas também não quer que elas sejam jogadas fora, são coisas suas das quais você não quer se desfazer.

Um belo dia, você resolve que vai sair da casa dos seus pais, encontra um pequeno apartamento para morar, nada muito luxuoso, mas que vai lhe servir muito bem nesses primeiros passos, o problema é que você não pode levar toda a tralha com você, vai ter que escolher o que pode ser "salvo" e o que vai, finalmente, ser levado pro lixo. Escolhas feitas, sua vida segue, agora só com as boas lembranças de tudo aquilo que você "se livrou".

No desenvolvimento de software nós também devemos aprender a fazer isso, jogar o entulho no lixo e aprender que às vezes, a única coisa que se salva são as "memórias", ou seja, as experiências que nós tivemos no desenvolvimento daquele artefato específico. Tentar ir mais além e buscar manter o entulho apenas porque algo foi investido nele pode custar muito mais caro do que recomeçar a caminhada.

Pegue o primeiro e jogue-o fora

No desenvolvimento de sistemas, especialmente quando nós não temos experiências prévias com aquele tipo de sistema, é esperado que haja um período de aquisição de informação onde o modelo da aplicação vai ser vago e muitas vezes não vai representar a realidade do domínio que ele busca reproduzir. Como DeMarco e Lister bem lembram em Peopleware:

"Speaking to a group of software managers, we introduced a strategy for what we think of as iterative design. The idea is that some designs are intrinsically defect-prone; they ought to be rejected, not repaired. Such dead ends should be expected in the design activity. The lost effort of the dead end is a small price to pay for a clean, fresh start. To our surprise, many managers felt this would pose an impossible political problem for their own bosses: "How can we throw away a product that our company has paid to produce?" They seemed to believe that they"d be better off salvaging the defective version even though it might cost more in the long run."

Aqui nós chegamos a uma encruzilhada, se foi investido dinheiro no produto, porque é que nós vamos jogar tudo fora, por que não salvar nada? Será que não há nada que possa ser reaproveitado?

Para a direção financeira garantidamente isso seria um desastre, ver todo o dinheiro investido escoando pelo ralo tão facilmente não deve ser fácil, o que não está sendo percebido é que mesmo que o artefato gerado não vá mais ser utilizado, ele foi a fonte de experiência e conhecimento de causa, o verdadeiro investimento não foi no que está sendo jogado fora, mas sim no que está ficando de conhecimento na equipe que produziu a "tralha".

Apoiar a pesquisa e a busca de novos métodos para se resolver os problemas deveria ser um trabalho comum para os gerentes de projeto, porque é com a inovação que nós realmente conseguimos o aumento de produtividade e não fazendo mais horas extras. Um gerente de projeto que pega no pé dos seus gerenciados sempre que eles cometem alguma falha ou que não é capaz de enxergar o valor que há ao chegar no "fim da linha" e recomeçar, vai fazer com que toda a equipe trabalhe na defensiva, sempre fazendo as coisas do único jeito que eles sabem fazer pra evitar puxões de orelha no futuro.

Errar é bom

É bom e necessário. Ninguém nasce sabendo de tudo na vida e menos ainda são aqueles que nunca cometem um erro ou tomam uma decisão errada, os que nunca o fizeram ou nunca escolheram ou nunca fizeram nada. As pessoas devem ser encorajadas a experimentar e até mesmo a cometer erros, afinal, é melhor que eles cometam os erros no ambiente controlado do trabalho do que quando estiverem implantando o sistema no cliente.

Nós não devemos ter medo de marcar um projeto para "morrer", às vezes, o custo de dar manutenção ou abrir mais um ponto de extensão (ou talvez até de "incisão") termina sendo muito maior do que se tudo fosse começado do zero. E o pior, no fim das contas você vai terminar tendo que dar manutenção em duas coisas, à novidade que você adicionou e ainda o sistema velho e inflexível que está lá e ninguém quer retirar.

Você também não precisa ser radical e sempre jogar tudo fora, em alguns casos, especialmente se o sistema já estiver em produção, não é simples remover todas as suas funcionalidades. Uma boa tática é começar a acessar o sistema indiretamente, através de "adapters" ou serviços, assim, no que você tiver uma nova implementação do sistema, basta trocar as implementações dos adapters ou serviços e a sua aplicação continua rodando normalmente.

Lembre-se sempre de que quando você leva a sua equipe a desenvolver as melhores soluções, não é só você e o cliente que ganham, as pessoas ficam mais felizes quando produzem coisas que atingem os seus níveis pessoais de qualidade e as experiências que elas puderam fazer no decorrer do projeto podem vir a ser fontes do aumento de produtividade que vocês tanto esperavam.