O desenvolvimento de software não é um problema industrial

Existe uma tentação persistente de tratar o desenvolvimento de software como uma atividade industrial.

A tentação é compreensível. A industrialização promete previsibilidade. Sugere que, com padronização suficiente, processos suficientes e aplicação rigorosa de boas práticas, os resultados podem tornar-se fiáveis. Definindo os elementos de entrada com clareza suficiente e restringindo o processo de forma adequada, seria possível obter resultados semelhantes repetidamente.

Esta lógica funciona de forma notável quando se fabricam objetos físicos.

Não funciona tão bem quando se constrói software.

Ainda assim, grande parte da forma como o software é planeado, gerido, estimado e avaliado assume que ele se comporta como um processo industrial que simplesmente ainda não foi suficientemente otimizado. Que o problema é de maturidade. Que, se as equipas adotassem o framework certo, seguissem a metodologia adequada ou cumprissem os padrões corretos com maior rigor, a incerteza acabaria por desaparecer.

Após anos suficientes dentro de projetos reais de software, essa crença torna-se difícil de sustentar.

Não porque as equipas sejam incompetentes. Não porque as ferramentas sejam insuficientes. E não porque as pessoas resistam à disciplina. Mas porque o desenvolvimento de software não é, antes de mais, um problema industrial.

É um problema de conhecimento e de design, realizado por pessoas, sob condições de incerteza que não desaparecem simplesmente porque gostaríamos que assim fosse.

Quando uma fábrica produz defeitos, assumimos que algo correu mal no processo. Quando o software se comporta inesperadamente, tendemos a assumir o mesmo. No entanto, esta analogia começa a falhar silenciosamente quando os sistemas ultrapassam uma dimensão trivial. Os sistemas de software não são montados a partir de componentes estáveis com comportamentos fixos. São construídos a partir de abstrações em evolução, de uma compreensão parcial do domínio e de pressupostos que só revelam as suas fragilidades depois de o sistema estar em utilização.

É por isso que duas equipas, utilizando a mesma linguagem, o mesmo framework, a mesma metodologia e o mesmo processo, podem produzir resultados radicalmente diferentes. Não porque uma tenha seguido as regras e a outra não, mas porque a atividade central não é a execução mecânica. É a interpretação e a tomada contínua de decisões.

Tratar o desenvolvimento de software como um problema industrial conduz a respostas previsíveis. Reforçamos os processos. Introduzimos mais controlos. Exigimos estimativas cada vez mais precisas cada vez mais cedo. Tentamos congelar requisitos. Priorizamos a conformidade em vez da compreensão. E quando a realidade se recusa a cooperar, culpamos a execução em vez de questionar o modelo.

O que muitas vezes fica por analisar é se o desejo de previsibilidade está realmente alinhado com a natureza do trabalho.

O software não se limita à implementação de requisitos; expõe mal-entendidos sobre eles. Não apenas codifica designs; testa os seus pressupostos. Todo o sistema não trivial ensina aos seus criadores algo que não sabiam no início. Essa aprendizagem não é uma falha de planeamento. É o próprio trabalho.

É aqui que os limites do enquadramento industrial começam a tornar-se visíveis. Ele trata a aprendizagem como desvio, a mudança como instabilidade e a incerteza como algo para eliminar, em vez de gerir.

Nada disto implica que o desenvolvimento de software seja caótico, desestruturado ou puramente criativo num sentido romântico. Há lógica, rigor e disciplina envolvidos—frequentemente em grande medida. Mas a disciplina, neste contexto, não resulta de fingir que o trabalho é previsível. Resulta de reconhecer onde não o é e de conceber práticas capazes de absorver essa realidade sem se romperem.

Muitas das frustrações que as pessoas experienciam em projetos de software não resultam da falta de processos, mas de um desalinhamento entre o processo e a natureza do trabalho. Quanto mais rigidamente um sistema é concebido para impor certeza, mais frágil se torna quando essa certeza não se concretiza.

Visto desta forma, problemas recorrentes como estimativas falhadas, descobertas tardias, reescritas, refatorações e redesenhos deixam de ser misteriosos. Não são sinais de imaturidade na área. São sintomas de tratar uma atividade exploratória e fortemente orientada ao design como se fosse uma linha de produção.

O desenvolvimento de software não está sob tensão porque não tenha conseguido tornar-se suficientemente industrial.

Está sob tensão porque continuamos a exigir que se comporte como algo que não é.