Um novo projeto de software é iniciado. Os gestores do projeto começam os rituais de levantamento de requisitos, modelagem e estimativas de custos e prazos. O foco é colocar esse software no ar, sua concepção é o projeto, é o objeto do contrato, é o que está sendo vendido e que vai ser listado em sua lista de conquistas em sua página do LinkedIn.
Mas a experiência na área de tecnologia nos mostra que o que vem depois é que mede de verdade o sucesso desse projeto. Manutenção é uma palavra que não inspira desenvolvedores, ninguém tatua essa palavra no próprio corpo, ninguém faz filmes de ficção científica sobre o tema, mas é uma das principais razões para existirem engenheiros de software profissionais.
Escrever código que funciona é fácil. É algo que qualquer um consegue fazer, basta paciência para aprender usando tutoriais, livros ou professores. Mas o profissional precisa sempre levar em consideração que amanhã alguém vai precisar alterar esse código e algum usuário pode ter um prejuízo se algo não estiver funcionando corretamente. Fazer funcionar é fácil, é a parte do trabalho que é uma ciência exata. Construir algo que é possível de manter funcionando é mais próximo de uma arte, um misto de experiência, intuição e criatividade.
Pensar nos custos de manutenção se torna ainda mais crítico quando você não tem uma equipe grande de desenvolvedores. A maioria das tarefas de manutenção não são possíveis de prever e quanto menos braços a disposição, menor o número de coisas que podem ser feitas em paralelo. Trabalhando sozinho, pode ser que você precise assistir sua cozinha pegando fogo enquanto você tenta apagar o incêndio no seu quarto.
Esses eventos não previstos que geram a necessidade de alteração do código de seu software é o que chamo de “dores de cabeça”. Quando uma dor de cabeça surge, as tarefas que você havia planejado precisam ser adiadas, talvez você precise trabalhar em finais de semana e madrugadas e em alguns casos até cancelar compromissos. Elas existem em todos os projetos, mas existem características que tornam um projeto mais suscetível a alguns tipos de dor de cabeça.
Para tentar entender melhor a quantidade de trabalho que podemos ter com a manutenção de um software no futuro, nós precisamos de um índice de dor de cabeça. Com esse índice, podemos analisar pelas características de nosso projeto, quais tipos de dor de cabeça vão afetar nossas noites de insônia. E é claro que isso não pode ser algo exato, com uma fórmula que vai cuspir um número que você pode usar em uma planilha de custos, mas ele pode te ajudar a decidir quais tipos de problema você está disposto a encarar baseado nas decisões de projeto hoje.
Mais funcionalidades = mais dor de cabeça
Este é o fator básico e mais óbvio deste índice. Quanto mais coisas seu software faz, maiores as chances de algo precisar de manutenção.
Seu software vai ter funcionalidades fechadas, como por exemplo funções que calculam algo sem nenhuma interação com atores externos e que portanto são fáceis de testar. Essas provavelmente não vão gerar muita dor de cabeça, a não ser por bug que ocorrem em casos que não foram pensados durante os testes.
Quando você tem funcionalidades em que partes de seu sistema dependem de outras partes do seu sistema, a chance de existirem esses casos de exceção que não foram pensados começa a aumentar. Uma dessas partes pode ser alterada e a interação entre as duas mudar de forma que novos bugs surjam.
Por isso, quando um usuário te pede para implementar algo que parece ser muito fácil, você sempre precisa se lembrar que isso pode virar uma bola de neve de dor de cabeça.
Cada funcionalidade de seu software deve aumentar 1 ponto em seu índice de dor de cabeça.
Bibliotecas e dependências
Uma das vantagens do ofício de desenvolvedor de software é que você pode reutilizar o trabalho de outros desenvolvedores. A cada novo projeto não precisamos criar do zero os sistemas operacionais, bancos de dados, bibliotecas e outros sistemas utilizados em nossa solução.
O problema é que você não tem controle sobre essas dependências por serem mantidas por outras empresas ou desenvolvedores de open source. E isso significa que a manutenção dessas partes do sistema mudam sem seu controle e podem gerar bugs em seu sistema. E é por isso que precisamos ter cuidado ao atualizar nossas dependências.
O que nos impede de usar para sempre as mesmas versões de bibliotecas que sabemos que funcionam? O motivo mais forte é que muitas vezes essas dependências são atualizadas porque uma brecha de segurança foi descoberta. E o outro motivo é que nossas dependências tem suas próprias dependências que podem afetar outras dependências de seu software quando você for forçado a atualizá-las.
Esses dois motivos nos forçam a acompanhar as versões atuais das dependências para manter nossas bibliotecas em versões próximas às versões mais atuais. Atualizar de uma versão para a seguinte já é complicado, mas quando você descobre que precisa fazer o upgrade de algo que está na versão 2 em seu sistema para a versão 10.0 na versão mais atual, comece a rezar.
Cada dependência de seu software deve aumentar em 2 pontos seu índice de dor de cabeça. Cada ponto de versão em que você está defasado em relação à versão mais atual de uma dependência, multiplique esses pontos por 5.
Integrações com outros sistemas
Assim como bibliotecas, integrar com outros sistemas nos poupa de ter que construir tudo que precisamos para que um sistema funcione. E assim como bibliotecas, APIs externas afetam nossos sistemas quando sofrem alterações ou apresentam algum problema.
A diferença é que nós podemos segurar um pouco atualizações de bibliotecas e continuar com as versões que estão funcionando até termos tempo para trabalhar nisso. Já mudanças em APIs têm um prazo para acontecer, e talvez você não tenha a opção de esperar. Ou não receba os avisos de que a API vai mudar. Ou simplesmente esteve tão ocupado que acabe esquecendo e só sendo lembrado quando algo no seu sistema para de funcionar.
Em alguns casos você precisa lidar com mudanças de comportamento de uma API que não aconteciam quando a integração foi feita. Pode ter sido alguma mudança que os desenvolvedores da API acharam que não iam causar muito impacto ou simplesmente alguns erros que você nunca havia visto começam a acontecer porque o sistema da API tem novos bugs ou não está escalando para a carga atual.
E ainda existe o maior problema que são APIs desativadas. Empresas desistem de projetos ou vão à falência e você vai ter que correr para pesquisar, testar alternativas e talvez tenha que construir as mesmas funcionalidades do zero.
Cada ponto diferente de seu código que faz uma chamada para uma API externa deve aumentar 50 pontos em seu índice de dor de cabeça. (Largue a planilha, eu disse que esses números não significam nada).
Legislação
Mudanças em leis podem afetar seu software. Podem ser exigências de como ele deve se comportar, (exemplo: leis de proteção à privacidade na internet). Ou podem afetar os dados utilizados, que vão desde a forma como impostos são calculados até a modelagem de dados (imagine se você tiver tabelas de cônjuges e de repente a poligamia é liberada por lei em seu país).
Essas mudanças nem sempre oferecem um prazo razoável, já que os legisladores não tem como prioridade estimar o quanto cada lei pode afetar sistemas que dependem dessa lei.
Para cada ponto em seu código em que existe um cálculo baseado em lei, adicione 100 pontos ao seu índice de dor de cabeça. Se seu software é usado em alguma área em que a legislação muda muito, adicione mais um número bem grande. Multiplique esse número grande pelo número de páginas da legislação.
O objetivo do índice não é que você procure pela dor de cabeça zero. Um sistema com índice zero com certeza é simples demais e não muito útil. A análise pelo índice serve apenas para que possamos entender os trade-offs que as decisões tomadas na concepção do software podem ter no decorrer de sua vida.
Além disso, a dor de cabeça de uma pessoa pode ser a oportunidade de outra. Você pode oferecer uma solução para algo que os outros consideram uma dor de cabeça. Ou simplesmente oferecer a terceirização da dor de cabeça, para que os outros possam se focar em questões mais centrais a seus negócios.