O pior débito técnico: desenvolvedor preguiçoso e sem estudo e a negligência no acompanhamento

Ward Cunningham criou este termo para representar
o seguinte problema:

quando desenvolvemos existe um dilema: escolher a
solução melhor, com melhor design, com código mais limpo, mas que
demora muito mais a ser feita, ou a solução mais
bagunçada, com design ruim, porém mais rápida de fazer?

A idéia é que, à medida que fazemos
código que não é tão bom, vamos aumentando o nosso débito com a
qualidade do código. Muitas vezes este débito
é criado para atender datas que são cumpridas em termos de cronogramas
ou porque o desvio do projeto já é tão grande que a qualidade virou um
item dispensável.

Não tiro a minha parcela de culpa na questão do débito técnico,
quantos projetos iniciamos com as melhores intenções do mundo, como
por exemplo utilizar integração contínua, Testes unitários, Refactoring
e Scrum e no meio dele algo sai errado e vai tudo por água abaixo.

Neste caso, vejo que muitas vezes, por estarmos acostumados com o mind
set de gestão tradicional command control (C2), achamos que quando o bicho
pega os métodos atuais não podem ajudar, então temos que voltar para as
formas antigas de controlar desvios e lidar com pessoas e iterações.

No meu caso, vejo que este tipo de problema aconteceu e acontece por dois
motivos. O primeiro é a falta de acompanhamento adequado na
parte técnica do projeto, este acompanhamento não feito pelo gerente do
projeto que cuida e deve cuidar de questões administrativas. Vejo que
esta é a responsabilidade de um Arquiteto de Software, Projetista ou
Líder Técnico. Quando trabalhamos com desenvolvedores mais novos e
menos experientes é extremamente necessário acompanhar o que está sendo
codificado e quando e por que estão sendo criados testes unitários.

Falo por experiência própria de quem já errou e teve e tem problemas com
esta questão. No caso dos testes unitários, participei de uma situação
recentemente que, por falta de comunicação e acompanhamento adequado da
minha parte (Arquiteto de Software), os desenvolvedores criaram testes
unitários para testar funções de acesso ao banco de dados em classes
DAO fazendo inserts, selects e updates. Não existe problema em criar
testes para isso, desde que existam regras de negócio ou validações mais
complexas envolvidas na aplicação ou no banco de dados. Então, neste
caso, todo um tempo foi gasto de maneira não tão adequada e sem muitos
benefícios.

É impressionante o fato de que ainda passamos por muitos problemas
de comunicação nos dias de hoje. Isso é bizarro porque é uma questão
tão básica e simples, mas mesmo assim pecamos muito nesta questão.

Apesar de ter vivenciado estes problemas relativos aos testes
unitários, tive vários benefícios e vantagens na utilização da
Integração Contínua com Hudson.

Mas uma coisa que a integração contínua não me deu foi códigos sem
débito. Acredito que nem seja o papel dela prover este tipo de coisas.
Vejo a integração contínua não como um servidor que você instala dentro
de um Jetty
e pronto, mas como um conjunto de
práticas como automação de build, testes unitários, versionamento de
código, políticas de branches, commits frequentes e fail fast.

Quanto à qualidade do código, para mim somente a revisão periódica de
código pode ajudar a mostrar estes débitos. Mas uma vez que você
consiga diminuir os gaps de comunicação, fazer revisões periódicas no
código como sugere o FDD por exemplo, ainda existe um débito a ser pago.

O desenvolvedor preguiçoso e sem estudos! É cada vez mais comum ver no
mercado desenvolvedores que não estudam. É incrível como é difícil
achar pessoas hoje em dia que saibam o que é um Servlet, fazer acesso
com JDBC, trabalhar com JSF sem escopo de Sessão, usar Spring sem
anotações.

Concordo que Java, no passado, tinha sérios problemas de produtividade e
complexidade para desenvolver atividades pontuais e corriqueiras, mas
uma vez que esta “geração” passou, vejo que hoje existe uma outra geração que tem dificuldade de trabalhar sem ter os frameworks
utilizados na maioria das aplicações ordinárias com arquitetura MVC e o
modelo anêmico. Sem falar nos desenvolvedores que viveram boa parte da
sua carreira trabalhando com frameworks feitos in-house que nem são
paredes isoladoras do desenvolvedor para o mercado da realidade. Acho
tão simples chegar em casa, baixar alguns jars ou ler um pedaço de
Java-Doc e fazer algumas classes para testar algumas funcionalidades e
aprender um pouco sobre novas coisas. A verdade é que poucos
desenvolvedores fazem isso. Qual o impacto disso?

A bagunça total no código! Este resultado só tende a piorar porque além de o pessoal não estudar, inicia-se um sentimento de que o
projeto está condenado e não tem salvação. A única salvação seria
começar outro projeto do zero, com uma nova arquitetura e novos
frameworks.

O problema disso (além de ser a realidade) é que é inviável em termos de
custos e muitas vezes a arquitetura está ok, a tecnologia é boa, mas foi mal desenvolvido ou mal projetado (design), quando foi projetado.

Então, se pegarmos aquela velha pesquisa que diz: “20% do tempo de vida
de um software é projeto, 80% é manutenção” caímos no problema que
afeta todo mundo. Por que os desenvolvedores só querem saber de
projeto? Por que eles não podem fazer um bom trabalho com o que existe?
Fazer refactoring, mudar o código, criar testes unitários, colocar
integração contínua.

Isso tudo acaba gerando a impressão nos gestores de que o programador
só quer saber de tecnologia e não quer saber em ajudar o negócio e
transformar software em resultado para empresa. O que acaba
desvalorizando o desenvolvedor e, de certa forma, deixando-o até com uma má imagem em algumas organizações.

Por mais que existam incentivos ao desenvolvedor, dando-lhe livros, sites,
blogs, dicas, feedback e problemas para ele resolver, se o cara não
estuda e corre atrás, não tem jeito. Não sei se isto pode ser considerado
um débito técnico, mas para mim é a pior coisa que tem e a que menos eu
vejo opções para ajudar e melhorar esta questão.

Parece que o desenvolvedor é visto como algo “ruim” e esta visão
parece vir dos próprios desenvolvedores. Por que a carreira em X como
desenvolvedor é errada? Por que estudar tanto e depois jogar tudo fora?
Bom, em outras áreas, como a engenharia, não vejo os caras estudar tanto e
trabalhar para depois jogar tudo pelos ares.

É triste, mas o desenvolvedor não se valoriza. Não digo que é errado
seguir um carreira em Y. Mas como já cansei de ouvir analisa dizendo
que odeia código e que não quer nunca mais programar na vida! Isso me
parece muito errado, e também controverso. Talvez isso também aconteça pela cultura
do nosso país, por isso gosto de pensar em
skills, e não em cargos.

Voltando à questão do débito, periodicamente se você pagasse que
fosse a parcela mínima já seria melhor do que não pagar nada, porque
todos sabemos que os juros são altos. O fato é que precisamos baixar
este débito, pois como já disse o Steve McConnell, se a empresa não se
preocupar com isso pode chegar um tempo em que mais se gaste tempo
corrigindo problemas no código do que adicionado novas funcionalidades.

O fato de existirem desenvolveres preguiçosos pode ser tanto pela
influência do ambiente e facilidades que ele encontra nele como por
exemplo ajuda de Arquitetos de Software mais experientes ou pela
própria pressão que os gerentes podem vir a exercer sobre os
desenvolvedores. Como também pelo próprio perfil das pessoas, de
comodismo.

Gostaria de saber o que vocês pensam sobre isso, se vocês têm experiências
positivas para diminuir o débito técnico e mudar este perfil de
comodismo de alguns desenvolvedores. Se quiserem compartilhar suas
experiências, elas serão bem-vindas, então comente aí! 🙂

Abraços e até a próxima.