O Pior Débito Técnico: Desenvolvedor Preguiçoso e Sem Estudo e a Negligencia 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 porem que demora muito mais a ser feita e claro outra opção é a solução mais bagunçada com design ruim porem mais rápida de fazer.
Não tiro a minha parcela de dulpa na questão do débito técnico, quantos projetos nos iniciamos com as melhores intenções do mundo, como por exemplo utilizar integração contínua, Testes unitários, Refactoring e Scrum e neio do projeto algo sai errado e vai tudo por agua a baixo.
Neste caso vejo que muitas vezes por estarmos acostumados com o mind set de gestão tradicional command control(C2) achamos que quando o bixo pega os métodos atuais não podem ajudar então temos que voltar para as formas antigas de controlar desviões e lidar com pessoas e iterações.
No meu caso vejo que este tipo de problema aconteu e acontece por dois motivos. O primeiro motivo é a falta de acompanhamento adequado na parte técnica no projeto, este acompanhamento não feito pelo gerente do projeto que cuida e deve cuidar de questões administrativas, vejo que esta é a resposábilidade de um Arquiteto de Software, Projetista ou Lider Técnico. Quando trabalhamos com desenvolvedores mais novos e menos experiêntes é extremamente necessário acompanhar o que esta sendo códificado e quando e por que estão sendo criando testes unitários.
Falo por experência prórpia de quem já errou e teve e tem problemas com esta questão. No caso dos testes unitários e participei de uma situação recetemente 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 existem regras de négocio 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 beneficios.
É impressionante o fato que ainda passamos por muitos problemas de comunicação nos dias de hoje. Isso é bizarro por que é 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 beneficios e vantagens na utilização da Integração Contínua com Hudson.
Agora 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. Negativo! Integração contínua é composto por um conjunto de práticas como automação de build, testes unitários, versionamento de código, politicas de braches, commits frequentes e fail fast.
Quando a qualidade do código para mim somente a revisão periodíca 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 peiodicas no código como sugere o FDD por exemplo, ainda existe um débito a ser pago.
O Desenvolvedor Preguisoço e Sem Estudos! Cada vez é mais comun ver no mercado desenvolvedores que não estudam. É incrível como é díficil 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 "gerção" passou vejo que hoje existe uma outra geração "Coca-Cola" que tem diculdade de trabalhar sem ter os frameworks utilziados na maioria das aplicações ordinarias 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 paredas isoladoras do desenvolvedor para o mercado a relaidade. 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 por que além do pessoal não estudar, inicia-se um sentimento de que o projeto esta 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 técnologia é boa, porem 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" caimos 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 oque 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 técnologia e não que saber em ajudar o negocio e transformar software em resultado para empresa. O que acaba desvalorizando o desenvolvedor e de certa forma deixando até como um papel promiscuo em algumas organizações neste país.
Por mais que existe incentivo ao desenvolvedor dando-lhe livros, sites, blogs, dicas, feedback e problemas para ele resolver, se o cara não estuda e corre atáz não tem jeito. Não sei se isto pode ser considerado um débito técnico mais 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 parecer 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 odéia código e que não quer nunca mais programar na vida. Isso me parece muito errado, também me parrece controverso. Talvez pela cultura do nosso pais isso também seja atrelado, por isso gosto de pensar em skills e não em cargos.
Agora voltando a questão do débito, periodicamente se você pagase que fosse a parcela mínima já seria melhor do que não pagar nada, por que todos sabemos que os juros são altos. O facto é que precisamos baixar este débito por que como já disse o Steve McConnell se a empresa não se preucupar com isso pode chegar um tempo em que mais se gaste tempo corrijindo 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 experiêntes 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.
Gostária de saber o que vocês pensam sobre isso, se você experiências possitivas para dimunir o débito técnico e mudar este perfil de comodismo de alguns desenvolvedores e quizer compartilhar suas experiência elas seram bem vindas, então comente ai! :)
Abraços e até a próxima.
A idéia é que a 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 complidas em termos de cronogramas ou por que o desvio do projeto já é tão grande que a qualidade virou um item dispensável.
Neste caso vejo que muitas vezes por estarmos acostumados com o mind set de gestão tradicional command control(C2) achamos que quando o bixo pega os métodos atuais não podem ajudar então temos que voltar para as formas antigas de controlar desviões e lidar com pessoas e iterações.
No meu caso vejo que este tipo de problema aconteu e acontece por dois motivos. O primeiro motivo é a falta de acompanhamento adequado na parte técnica no projeto, este acompanhamento não feito pelo gerente do projeto que cuida e deve cuidar de questões administrativas, vejo que esta é a resposábilidade de um Arquiteto de Software, Projetista ou Lider Técnico. Quando trabalhamos com desenvolvedores mais novos e menos experiêntes é extremamente necessário acompanhar o que esta sendo códificado e quando e por que estão sendo criando testes unitários.
Falo por experência prórpia de quem já errou e teve e tem problemas com esta questão. No caso dos testes unitários e participei de uma situação recetemente 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 existem regras de négocio 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 beneficios.
Apesar de ter vivenciado estes problemas relativos aos testes unitários, tive vários beneficios e vantagens na utilização da Integração Contínua com Hudson.
Agora 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. Negativo! Integração contínua é composto por um conjunto de práticas como automação de build, testes unitários, versionamento de código, politicas de braches, commits frequentes e fail fast.
Quando a qualidade do código para mim somente a revisão periodíca 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 peiodicas no código como sugere o FDD por exemplo, ainda existe um débito a ser pago.
O Desenvolvedor Preguisoço e Sem Estudos! Cada vez é mais comun ver no mercado desenvolvedores que não estudam. É incrível como é díficil 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 "gerção" passou vejo que hoje existe uma outra geração "Coca-Cola" que tem diculdade de trabalhar sem ter os frameworks utilziados na maioria das aplicações ordinarias 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 paredas isoladoras do desenvolvedor para o mercado a relaidade. 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?
O problema disso(além de ser a realidade) é que é inviável em termos de custos e muitas vezes a arquitetura está ok, a técnologia é boa, porem 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" caimos 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 oque 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 técnologia e não que saber em ajudar o negocio e transformar software em resultado para empresa. O que acaba desvalorizando o desenvolvedor e de certa forma deixando até como um papel promiscuo em algumas organizações neste país.
Por mais que existe incentivo ao desenvolvedor dando-lhe livros, sites, blogs, dicas, feedback e problemas para ele resolver, se o cara não estuda e corre atáz não tem jeito. Não sei se isto pode ser considerado um débito técnico mais 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 parecer 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 odéia código e que não quer nunca mais programar na vida. Isso me parece muito errado, também me parrece controverso. Talvez pela cultura do nosso pais isso também seja atrelado, por isso gosto de pensar em skills e não em cargos.
Agora voltando a questão do débito, periodicamente se você pagase que fosse a parcela mínima já seria melhor do que não pagar nada, por que todos sabemos que os juros são altos. O facto é que precisamos baixar este débito por que como já disse o Steve McConnell se a empresa não se preucupar com isso pode chegar um tempo em que mais se gaste tempo corrijindo 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 experiêntes 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.
Gostária de saber o que vocês pensam sobre isso, se você experiências possitivas para dimunir o débito técnico e mudar este perfil de comodismo de alguns desenvolvedores e quizer compartilhar suas experiência elas seram bem vindas, então comente ai! :)
Abraços e até a próxima.
