Este post é para os programadores, como eu, que certamente percebem que nesse ramo existem alguns padrões de acontecimentos a que estamos sempre sujeitos, por mais que tomemos cuidado no desenvolvimento e manuteção de nossos programas. Aproveite para rir quando ler, porque quando isso acontece com você, não tem muita graça.

1. Qualquer programa, quando em execução, torna-se obsoleto.
   
   Quantas vezes temos que ouvir opiniões como “a gente podia começar um novo programa”, com sugestões como usar uma nova linguagem (vamos usar o Go, a nova linguagem que o Google criou!) ou plataforma (podemos começar uma versão para o iPad 2!), ou permitir que tudo seja automatizado (seria legal se a gente não precisasse abrir o programa, ele devia adivinhar quando seu uso é necessário!). Ou seja: Agora que está pronto, podemos começar um melhor, não acha?
   
   
2. Qualquer programa acaba mais caro e demorando mais para ser concluído.
   
   No começo tudo é simples: “só preciso de um cadastro de telefones, uma agenda”, diz o cliente. Ao longo do projeto novas requisitos são adicionados, mais dados, mais telas, mais usuários, prazos estendidos… caos. No fim o cliente exige a entrega de um ERP completo, com cálculo de fluxo de caixa, consulta de crédito, emissão de boletos, sistema de cobrança e comunicador interno (chat! todo cliente adora um chat), tudo isso rodando em Windows, Linux ou Mac. E a razão de tudo isso está na próxima regra.
   
   
3. Se um programa é útil, ele precisa ser alterado.
   
   Alterações, só isso. Parece simples essa palavra, mas na área de desenvolvimento ela nunca vem no singular, são sempre alterações. Desde um simples botão que não está num lugar ‘de destaque’, até a estrutura de uma tabela de banco de dados de clientes, que pode repentinamente passar a permitir cadastros conjuntos de marido e esposa, e começar a criação de um monstro digital.
   
   
4. Se um programa é inútil, ele precisa ser documentado.
   
   Simplesmente porque não existe mais nada a fazer com ele. Se ele precisasse de alterações, não haveria tempo a ‘desperdiçar’ com isso. Não quer dizer que documentar seja ruim, mas é o que muitos pensam. Deve ser feito sempre, mas exige organização e padronização. Como é quase sempre um item deixado de lado, a documentação de software só é lembrada quando não há nada para o programador fazer, então o gerente diz “documente aquele programa que envia e-mail em massa, porque um dia a gente pode precisar dele”.
   
   
5. Qualquer programa irá expandir-se até consumir toda memória disponível.
   
   Todo programador aprende sobre gerenciamento de memória no seu curso, faculdade, certificação ou quando está lendo o tutorial de ASP.Net para iniciantes. Mas depois esquece de tudo, e não se importa em limpar variáveis não usadas ou fechar conexões ociosas com o banco, geralmente porque “tem bastante memória livre no computador/servidor”. Quando a memória livre acaba, o pesadelo começa.
   
   
6. O valor de um programa é proporcional ao tamanho de suas respostas.
   
   Quanto vale um software de calculadora comum programado em C#? Pouco. Quanto  vale um software que simule uma HP 12C em Pascal? Um pouco mais. Mas quanto vale um programa de gestão empresarial que controle clientes, vendas, custos e gere relatórios em PDF que ultrapassam os Megabytes de tamanho? Muito. Sério.
   
   
7. A complexidade de um programa cresce até extrapolar as capacidades de quem o mantém.
   
   Essa é a regra mais comum de se perceber. Todo programa chega num ponto onde suas alterações não podem mais ser feitas por uma pessoa só por falta de tempo. Então são contratados mais desenvolvedores, depois são criadas equipes para cada parte do sistema, e então cada módulo do sistema vira um novo sistema, com novos programadores e equipes e assim por diante.
   
   

Parece exagero (tá bom, algumas são exageradas), mas estas regras estão presentes no nosso dia-a-dia e não tem como escapar, no máximo se preparar para elas. Como? Sendo aquele que indica a presença de uma delas, e não aquele que causa a aplicação de alguma.