Se arquitetos tivessem de trabalhar como programadores (1995)
Um texto humorístico de 1995 que imagina arquitetos obrigados a trabalhar sob condições da indústria de software provoca uma crítica mais ampla sobre como projetos de tecnologia modernos são conduzidos: requisitos vagos e mutáveis, prazos irrealistas, muito processo e “responsabilidade sem autoridade.” Comentadores comparam software à construção e a outros campos de engenharia, debatendo se a programação deveria ser mais parecida com o design físico regulado e sujeito a responsabilidade jurídica, ou se sua maleabilidade justifica o caos iterativo. Muitos culpam incentivos corporativos, a cultura de MBA e o “Agile” de fachada pela disfunção, enquanto outros observam que clientes, especificações ruins e restrições políticas são universais entre profissões.
Reação geral à sátira
- Muitos consideram o texto dolorosamente preciso para o trabalho moderno de software, especialmente no que diz respeito a requisitos vagos, exigências que mudam e restrições arbitrárias.
- Outros veem isso como uma vitimização exagerada de “programadores” que ignora disfunções semelhantes em outros campos baseados em projetos.
- Vários observam que o artigo é claramente humor, mas que ressoa porque reflete patologias comuns do setor.
Paralelos com a construção e a arquitetura no mundo real
- Pessoas com experiência em construção/arquitetura relatam problemas notavelmente semelhantes: clientes indecisos ou em busca de status, mudanças de última hora, ideias irrealistas (por exemplo, piscinas em terraços ou em pódios adicionadas tardiamente) e especificações incompletas ou erradas.
- Trabalhos residenciais de alto padrão e com “clientes ricos” supostamente se parecem muito com a sátira: redesenhos constantes, modas de revistas e exigências estruturais caprichosas.
- Outros enfatizam as diferenças: arquitetos e engenheiros enfrentam forte regulamentação, responsabilidade jurídica pessoal, preocupações com segurança e ciclos de mudança mais lentos e caros.
Principais pontos de dor no desenvolvimento de software
- Estimativa sob incerteza: especificações mínimas, atomização forçada do trabalho em “points” e punição independentemente da precisão da estimativa.
- “Responsabilidade sem autoridade”: ser culpado por problemas que você não pode ou não tem meios de resolver.
- Interrupção constante: emergências, trocas de contexto e reuniões de status obrigatórias que não ajustam os prazos.
- O “agile corporativo” é amplamente criticado por ser pesado em cerimônias, microgerenciador e desconectado das ideias originais do agile.
Papel de gestores, PMs e clientes
- Alguns argumentam que bons product/project managers deveriam proteger os engenheiros de clientes caóticos; outros dizem que os PMs muitas vezes viram outra fonte de caos e microgerenciamento.
- Há divergência sobre se desenvolvedores devem falar diretamente com clientes: alguns veem isso como essencial para entender problemas; outros alertam sobre promessas e gestão de expectativas.
Debate sobre analogias: software vs engenharia física
- Um lado: construção e software são fundamentalmente diferentes (bytes vs tijolos, reversibilidade, velocidade do feedback, fragmentação de papéis), então a analogia é “falsa”.
- O outro lado: as analogias ainda são úteis para expor o quão absurdas certas expectativas em software parecem quando transpostas para um domínio físico.
Crítica organizacional/gerencial mais ampla
- Vários comentários culpam a “MBA-ificação”, a tomada de decisão guiada por planilhas, o foco trimestral e gestores profissionais desconectados do trabalho.
- Outros observam que praticamente todas as grandes organizações são disfuncionais, tanto em software quanto em engenharia tradicional.