Taverna /dev/All

Débito técnico: como lidar com o monstro inevitável?

Que houve com este fórum que anda meio parado? Eu mesmo ando às voltas com este tema cabuloso, o débito técnico, e sequer tinha tido a ideia de trazer pra discussão aqui ou em qualquer lugar…

O tema é tão vasto, mas num fórum como este acho que as perguntas mais interessantes pra galera poderiam ser (lista não exaustiva, obviamente):

  • quais as experiências mais cabulosas que vocês tiveram com o débito técnico não pago?
  • porque (ao que me parece) a regra é o débito técnico se acumular até o ponto em que o software fica intratável, ao invés de ser levado a sério desde o dia zero, no planejamento e alocação de tempo, pessoal e recursos?
  • como mitigar de forma sustentável para o negócio? Esta é meio capciosa, para mitigar precisamos sempre desenvolver com as melhores práticas e estar sempre “arrumando a casa”, com refatorações e tudo mais, mas até quanto cada empreendimento consegue arcar com o tempo de desenvolver nos trinques antes de entregar e/ou ficar pagando frequentemente o débito criado?
  • como convencer stakeholders da importância de investir esse tempo? Isto tem relação com a pergunta anterior, pois a geração de valor rápido e abundante pelo software é o que move o negócio, o time-to-market é a força que puxa o desenvolvimento das features e o $$$ é escasso principalmente no início.

Minhas opiniões:

Produzir software sem criar muito débito técnico só é possível com muita experiência. Os cursos, mesmo os de nível superior, pecam gravemente neste aspecto. Muito pouca gente sai dominando boas práticas, sequer as entende em um nível mínimo. Neste vídeo Fabio Akita defende a necessidade de se ter alguém com experiência na área como sócio e que os juniores devem trabalhar sob a supervisão de sêniores. Em se tratando de uma referência da área, é como um reconhecimento de que não dá para fazer as coisas bem feitas sem a experiência e não é possível adquiri-la sem o contato com quem já as têm.

Somado a isso, temos a ignorância de muitos empreendedores que buscam somente gente inexperiente ou com pouca experiência para baratear sua mão-de-obra. Para muitos leigos, a área costuma ter uma certa aura mística (olha o perigo!) e o menino do computador é capaz de fazer brotar o que os clientes desejam em seus sonhos mais selvagens. Dá para pagar barato naquele jovem que está começando (freela/estagiário/recém-formado/autodidata/whatever) que as coisas vão acontecendo, ainda que da forma errada e que o inexperiente candidato a desenvolvedor nem tenha consciência disso (mesmo com formação, ela é falha).

Mas mesmo entre quem empreende de maneira mais séria, o assunto precisa ser mais divulgado e as pessoas educadas a esse respeito. Nos acostumamos a ficar maravilhados com a tecnologia mas não aprendemos que programar é árduo, difícil, que software degrada de qualidade, que é preciso dedicar tempo ($$$) para mantê-lo manutenível, que eventualmente ele pode virar legado (termo usado de forma pejorativa, significando o abacaxi que nos deixaram) que ninguém consegue mais manter e os clientes abrindo um ticket de suporte atrás do outro… Enfim, que nem tudo são flores e é preciso pôr esse custo na conta desde o dia zero. Este outro vídeo explica muito bem o que acontece em termos leigos e ainda cita um artigo fantástico: https://www.inf.ed.ac.uk/teaching/courses/seoc/2004_2005/resources/bullet11.pdf.

Quantos de nós aqui trabalhamos a maior parte do tempo com software gostoso de manter e com as grandes bolas de lama?

Débito técnico é algo que parece muito complexo e muitos dizem ser insolúvel de ser resolvido, mas como sou arrogante tenho uma solução razoavelmente simples pra coisa.

Ver o código fonte como ferramenta vital de trabalho

Em equipes com alta rotatividade este é um grande desafio: mas a equipe precisa entender que a qualidade do código fonte e da arquitetura é diretamente proporcional à qualidade do seu ambiente de trabalho.

Então este esforço de conscientizar a equipe é vital.

Entender que o ego individual deve ser controlado

Este é um problema: não raro o déficit técnico nasce de preferências essencialmente pessoais de um indivíduo ou pequeno grupo, e não do problema que deve ser resolvido por aquele código/arquitetura.

E esta é a parte mais difícil de ser resolvida pois envolve cutucar o status quo alheio.

** Resumindo **

A solução é simples, mas envolve conscientização e cutuque no status quo alheio, então é difícil de ser resolvida.

PS: sobre este fórum parado…

Voltar a lidar com isto aqui.

Acho que todos esses fatores são relevantes, porém me chama atenção que meu post disserta sobre as pressões externas (ao desenvolvedor) que influem na geração do débito técnico e sua resposta se concentra no próprio desenvolvedor. Eu presumo que quem produz código porco (muita gente, infelizmente) não o faz porque é pessoalmente relapsa ou inconsequente e sim porque a formação é falha e, conforme essas pessoas ganham experiência, passam a apreciar melhor a dimensão organizacional do software.

O que você colocou certamente é um resumo do que deveria ser melhor trabalhado na formação de alguém que vai trabalhar com software. No entanto, o problema não acaba aí não: o papel da gestão em reconhecer o problema (quantos estartapeiros sabem que ele existe ao começar um negócio?), ajustar as expectativas, investir na prevenção e correção dos problemas que você citou (se o gestor/dono é leigo, como ele sabe que os estagiários e juniores que recrutou estão fazendo as coisas direito?), pesar os débitos técnicos no trade-off das entregas a toque de caixa e alocar real tempo para mapeá-los e consertá-los, etc., etc., etc.

A gestão pode drasticamente afetar as coisas para o bem e para o mal, inclusive nesse aspecto. Nem sempre as forças que provocam os débitos estão na decisão do desenvolvedor, é preciso ter isso muito claro.

itexto