The myth of software time estimations

The article treats software development as an unknown and dangerous terrain, so estimating completion dates is described as unrealistic. It links this uncertainty to the limits of predicting arbitrary programs, then argues that even careful teams face unpredictable problems, shifting requirements, and human factors.

Fichamento

#

• O texto compara o desenvolvimento de software a atravessar uma mata escura e sem mapa, em que só se conhece a direção geral.
• Afirma que estimar com precisão o tempo de desenvolvimento é uma expectativa irrealista e uma tarefa vã.
• Relaciona essa limitação à impossibilidade de prever sempre se um programa arbitrário vai rodar para sempre ou encerrar.
• Diz que métodos formais e programas provadamente corretos são exceções pouco praticadas.
• Sustenta que escrever e manter código é uma atividade caótica, sujeita a problemas súbitos e imprevisíveis.
• Relata que, em projetos, as partes que mais consomem tempo costumam ser subestimadas ou nem previstas no planejamento inicial.
• Observa que usuários, vários desenvolvedores, erros humanos, questões de gestão e mudanças de mercado aumentam a imprevisibilidade.
• Explica que as estimativas de tempo existem porque são moda, porque negócios e vendas fazem promessas futuras e porque muitos aceitam a prática como se os outros estivessem certos.
• Diz que até tarefas simples podem esconder imprevistos que tomam semanas de trabalho.
• Afirma que estimativas de tempo levam a cortar etapas e a produzir software simplificado demais para problemas que depois ficam mais complexos.
• Chama isso de complexity debt e descreve o efeito de ter de estender interfaces e modelos de dados básicos para atender casos mais complexos.
• Diz que estimativas consistentemente precisas podem sinalizar um produto quebrado ou um contexto de baixa dificuldade, não necessariamente um processo saudável.
• Recomenda usar Kanban puro sem estimativas de tempo.
• Defende comunicar que a empresa não fornece estimativas de tempo de desenvolvimento e considera essa prática prejudicial ao processo.
• Propõe usar estimativas de dificuldade sem compromisso com prazo, combinadas com tempo decorrido, número de usuários afetados, valor para o produto, confirmação do bug e importância dos usuários atingidos.