Como posso ser pago pela redução da dívida técnica?

Atualmente, estou trabalhando para uma pequena empresa que possui poucos produtos tecnicamente complicados. Sou o único desenvolvedor de um deles. Há cerca de um ano, obtive a versão legada do produto e comecei a "apoiá-lo".

O cliente fala apenas sobre novos recursos, valor comercial e outros desse tipo. O problema é que, embora o código esteja em C #, é bastante processual. Não há abstrações, as classes são usadas apenas onde o Visual Studio as requer - Formulários, por exemplo. As implementações dessas classes são realmente terríveis e o código é realmente difícil de manter.

Durante todo esse ano, passo meu próprio tempo na refatoração. Na versão mais recente, existem abstrações bonitas e tal. Eu tive que reimplementar vários componentes do zero e realmente sinto que adicionar novos recursos ou alterar o comportamento desses componentes é MUITO mais fácil do que para outros.

O problema é que passo meu próprio tempo. Gosto muito dos resultados, mas não gosto de trabalhar 12 horas por dia. Você já esteve em situação semelhante? O que devo tentar? Eu já tentei discutir isso, mas ainda não obtive sucesso.

Estou com medo do momento em que decidimos implementar o novo recurso que requer muitas alterações no código legado. Isso pode ser chocante para o cliente: por que você precisa de 8 horas para alterar esses ícones? O cliente simplesmente não se importa com a necessidade de alterar 500 lugares no código. E eu também deveria encontrar todos esses 500 lugares primeiro.

Alguma ideia?

Etapa 1: Pare de trabalhar horas extras não remuneradas.

Você já treinou seu cliente e gerente por um ano para acreditar que a taxa atual de desenvolvimento é o que deveria ser esperado. Isso é parte do motivo pelo qual eles não entendem por que uma coisa "simples" pode levar um dia inteiro para ser feita. Você não precisa mantê-los reféns e tentar prejudicar o projeto. Mas você precisa explicar que as expectativas deles são muito altas e você precisa de outro desenvolvedor ou mais tempo antes do prazo. Lembre-se de mencionar especificamente ao seu gerente que você está trabalhando horas extras sem remuneração e que planeja não fazer isso tanto. Mesmo se você reduzir para 9 horas por dia, a diferença será notada. Se o seu gerente perguntar por que você não está concluindo seu trabalho, você pode apontar para o fato de que fez questão de avisá-lo de que esse seria o caso.

Etapa 2: faça anotações

Só porque você não tem tempo para fazer o trabalho, não significa que não será mais fácil quando o trabalho (espero) terminar. Acompanhe as idéias que você tem para corrigir o código e as traga em reuniões para que outras pessoas estejam cientes de suas preocupações. Eventualmente, você atingirá um ponto lento ou as pessoas começarão a entender que suas preocupações têm valor. Quando chegar esse momento, você já terá algumas idéias básicas sobre o que fazer, em vez de ficar seco, porque não vê uma seção de código há algum tempo.

... o código é realmente difícil de manter.

Este é o seu caminho para a gerência. Demonstre que o custo de "apenas" corrigir os bugs e adicionar novas funcionalidades é maior do que o de refatorar e reescrever o código.

Por exemplo, se com o código atual um novo recurso levar 2 semanas para adicionar e, em seguida, uma quantidade significativa de tempo para manter (por exemplo, 1 dia por semana), mostre que, com a refatoração de uma semana, você pode concluir o desenvolvimento em 1 1/2 semanas, mas você reduzirá a manutenção para 1 dia por mês (ou menos). Esses números mostram que o que você está fazendo é rentável a médio e longo prazo, embora exista um custo a curto prazo.

Embora a empresa possa não gostar de gastar o dinheiro agora, verá que os benefícios potenciais são muito maiores - ou seja, você será mais produtivo gerando mais código em menos tempo e esse código terá melhor qualidade.

Aplique a regra dos escoteiros : deixe o código um pouco mais organizado (ou seja, com menos dívida técnica) toda vez que você tocar nele.

Reserve tempo para fazer isso em todas as estimativas que você fornecer. Então, magicamente, com o tempo, a dívida técnica desaparecerá e você será pago por isso.

Essa abordagem é muito mais fácil do que tentar explicitamente dedicar tempo (e, portanto, convencer os clientes / gerentes a pagar) pela dívida técnica. Dá a você uma sensação muito maior de profissionalismo e um "trabalho bem feito". E, finalmente, seus clientes e gerentes agradecerão por isso a longo prazo, mesmo que não entendam bem como isso aconteceu ...

Essa é mais ou menos a triste realidade da programação de manutenção. Você está preso ao que é designado para manter e se a pessoa que paga as contas não deseja pagar pelo que considera mudanças sem benefício, essas alterações tendem a não ser realizadas.

Se você deseja defender essas alterações, mantenha um registro de todos os lugares que você precisa alterar para obter a atualização mais simples. Após algumas alterações, discuta esse log com seu gerente. Se você pode documentá-lo, há uma chance (embora muito pequena) de que a pessoa com as cadeias de bolsa perceba que é realmente mais barato a longo prazo limpar o código agora, pois isso fará com que as alterações futuras sejam mais baratas.

Suas chances de vender esse aumento quanto mais tempo for esperado que este produto esteja em uso. As chances também aumentam se uma falha no produto provavelmente causar um problema de relações públicas para o cliente ou custar dinheiro ao cliente.

Salvo isso, aprenda o que puder e vá para outra posição com menos manutenção.

Você precisa mostrar à sua gerência como a refatoração e a melhoria do produto beneficiarão a empresa.

É provável que o cliente não se importe se o código é bonito ou feio, desde que funcione, e a gerência não deseja explicar ao cliente que o que ele já pagou foi mal projetado e mal implementado. Ao mesmo tempo, a gerência não estará disposta a comer o custo do tempo de desenvolvimento que não melhora o produto de alguma maneira visível (faturável).

Então ... você precisa convencer a gerência de que as alterações propostas ajudarão a empresa:

• Mostre a eles que uma arquitetura melhor permitirá adicionar novos recursos mais rapidamente.
• Explique que, continuando no caminho atual, eles se pintarão em um canto.
• Dê exemplos de alterações que são muito caras para fazer no sistema atual, mas que seriam simples e baratas com um design melhor.
• Acompanhe o tempo gasto mantendo o código legado e adicionando recursos vendáveis. - Ajude-os a explicar aos clientes existentes e futuros que, enquanto o sistema existente era muito bom, a nova arquitetura modernizada permitirá muitas grandes melhorias, maior confiabilidade e assim por diante.
• Reduza o risco associado às alterações que você propõe. Os gerentes são avessos ao risco, e mudanças radicais em um sistema existente parecem inerentemente arriscadas.
  • Priorize a modernização dos vários componentes de acordo com o custo e o benefício e verifique se o gerenciamento concorda com suas prioridades.
  • Use o teste de unidade para ajudar a garantir que os componentes modernizados sejam compatíveis com o código legado restante.
• Acompanhe o progresso do esforço de modernização. Mostre os benefícios assim que possível, mas lembre a todas as partes que há mais trabalho a fazer.

Você pode não perceber, mas Johnny Cash previu o movimento de refatoração e escreveu uma música sobre a melhor maneira de refatorar uma grande base de códigos existente.

Obviamente, ele teve que envolvê-lo em uma metáfora automotiva para que seu público se identificasse.

"Uma peça de cada vez" - Johnny Cash

Parece que você pode cobrar do cliente pelo tempo que a mudança "deve" demorar e ainda sair MUITO à frente no longo prazo.

Se você gosta de limpar o código (e parece que você faz pelo menos um pouco), vá em frente e continue fazendo isso, mas não se queime. Isso não agrada a você, sua empresa ou seus outros clientes.

Certifique-se de que seu gerenciamento e qualquer pessoa que trabalhe com o cliente saiba que o código não está na melhor forma para que eles possam tomar uma decisão informada - apenas porque você possui esse código não significa que você deve tomar decisões de negócios sobre ele, se eles não estiverem cientes dos problemas com o código, não poderão fazer seu trabalho.

Embora o aplicativo do cliente tenha alguma dívida técnica, não se esqueça, eles provavelmente foram cobrados com um pequeno desconto. Eles podem não ter sido informados disso, mas é o que acontece quando você faz o lance mais baixo.

Eles precisam decidir se desejam pagar o preço total pelas alterações dos recursos ou ficar sem eles. A escolha é deles. Você pode deixá-los tomar a decisão ou continuar trabalhando de graça. Você pode tentar mencionar o trabalho de limpeza realizado e oferecer um pequeno desconto pelo trabalho concluído. Novamente, a escolha é deles.

A maneira como eu abordaria isso é começar com a explicação do conceito de dívida técnica para seus chefes, para garantir que eles a recebam. Aborde-o de uma linha de fundo, perspectiva de negócios. Sempre que eles solicitam um novo recurso, a dívida técnica acumulada no produto afeta sua eficiência e, portanto, cada recurso custa um pouco mais devido a essa dívida.

Depois que eles entenderem o que você está falando, tente negociar um pouco do seu tempo para reduzir a dívida técnica. Na minha empresa, tivemos um êxito razoável ao solicitar 10% do tempo de cada desenvolvedor para trabalhar na redução técnica da dívida.

Depois de reservar um tempo para trabalhar nisso, certifique-se de usá-lo (e não faça apenas 10% de horas extras para fazer isso - atenha-se às suas armas). Crie um catálogo de itens de dívida técnica, priorize-os e comece a esculpir. Você tem que comer o elefante uma mordida de cada vez.

E não se esqueça de levar em consideração ferramentas melhores. O resharper é uma ótima ferramenta de refatoração que se conecta ao Visual Studio.