Mudança pequena, mas complexidade alta: explicando o custo oculto de algumas tarefas para não técnicos.

O programador que trabalha com gestores, supervisores ou clientes não técnicos tem seus desafios, mas um que sempre aparece é que, uma tarefa aparentemente fácil pode demorar mais que uma vista como ampla e complexa.

Essa percepção geralmente acontece por causa do impacto percebido no sistema e das alterações no Front-End da aplicação. Mas o fato é que, às vezes, coisas que não geram muito impacto ou mudanças significativas podem ser muito custosas a nível de trabalho, isso guarda alguma relação com a chamada regra do 80/20, sendo essas as responsáveis por 80% do trabalho, mas que geram 20% do resultado.

Como um programador pode lidar com isso?

Eu pessoalmente gosto de fazer analogias que estão ao alcance do entendimento de qualquer um, por exemplo, explicar como que a troca de uma peça grande e cara de uma máquina pode ser fácil e rápido, enquanto que um pequeno componente barato, mas que precisa de vários tipos diferentes de ferramentas e processos pode demorar muito.

A programação também é assim, sobretudo em arquiteturas altamente acopladas, algumas mudanças podem implicar em mexer em bases complexas que podem repercutir em vários outros pontos da aplicação, deixando assim, tudo mais complexo e demorado, embora não pareça para aqueles que não têm esse conhecimento.