Pode Ser Feito (2003)
Anedotas sobre André Bensoussan projetando um componente complexo do sistema de arquivos do Multics inteiramente no papel provocam um debate mais amplo sobre como o software era — e ainda poderia ser — construído com foco profundo, requisitos claros e ferramentas mínimas. Os comentários contrastam a era de escritórios silenciosos, sistemas pequenos mas conceitualmente difíceis e forte domínio técnico com os fluxos de trabalho atuais, interrompidos, com especificações mutáveis sob o “ágil” e pilhas extensas de dependências mal documentadas. Muitos veem o design cuidadoso antecipado, a colaboração próxima com especialistas do domínio e os documentos de design escritos como habilidades subestimadas que poderiam melhorar significativamente a qualidade do software moderno, mesmo que as restrições que antes forçavam esse rigor já não existam.
Programação com Papel e Lápis & Contexto Histórico
- Muitos se lembram de ter aprendido ou trabalhado com acesso muito limitado a computadores (papel, cartões perfurados, ciclos de compilação de uma semana).
- Isso forçava raciocínio cuidadoso, menos iterações e muitas vezes levava a código que funcionava na primeira execução.
- Vários veem a história do Multics como parte de uma era mais ampla de “meça duas vezes, corte uma vez”, quando o tempo de computação era escasso e os terminais não tinham distrações.
- Outros observam que isso também pode ter funcionado como um filtro: só pessoas altamente motivadas persistiam sob essas restrições.
Requisitos, Casos Limite & Especificações em Mudança
- Há forte concordância de que requisitos claros e estáveis, e APIs bem definidas, tornam a produção de código de alta qualidade muito mais viável.
- Problemas modernos: metas ambíguas, feedback tardio de stakeholders, mudanças constantes de escopo rotuladas como “ágil”, e pressão por prazos e “velocidade”.
- Debate sobre ágil: alguns dizem que ele responde a mudanças inevitáveis de requisitos; outros dizem que normaliza a mudança constante e incentiva alterações irresponsáveis.
- Casos-limite são uma grande fonte de bugs e complexidade. Alguns argumentam que casos raros devem ser tratados manualmente; outros dizem que, em escala, até 1% afeta milhões e precisa ser projetado.
Design, Documentação & Pensar Antes de Codificar
- Vários enfatizam que conseguir escrever o problema e a solução proposta é sinal de verdadeira compreensão.
- Documentos curtos de design e diagramas são vistos como ferramentas de pensamento, não burocracia.
- Alguns têm dificuldade em projetar no papel, dizendo que só entendem sistemas ao digitar e iterar; outros dizem que isso é uma habilidade treinável.
- O desenvolvimento orientado a testes é sugerido como um análogo moderno de “projetar primeiro”.
Expertise de Domínio & Mentalidade de Engenharia
- Um motivo importante para o feito do Multics ter sido possível: o programador também era um profundo especialista no domínio.
- Muitos argumentam que o valor real está em entender o domínio do problema e moldar requisitos, não apenas traduzir especificações em código.
- Há preocupação de que muitos desenvolvedores modernos não tenham compreensão de ponta a ponta e tratem desempenho e robustez como detalhes secundários.
Ambiente de Trabalho, Escala & Reações Emocionais
- Ambientes antigos: escritórios privados silenciosos, mesas grandes, sem notificações, gestão tecnicamente competente.
- Hoje: interrupções, reuniões, proliferação de ferramentas e sistemas cada vez mais interconectados e APIs externas.
- Alguns se sentem inspirados e nostálgicos; outros são céticos, observando que a complexidade moderna e as integrações confusas tornam a perfeição “de uma passagem” irrealista.
- Um sentimento recorrente: muitos desenvolvedores sentem-se subutilizados, fazendo trabalho CRUD/publicitário de baixo impacto em vez de sistemas fundamentais, o que leva à frustração e ao cinismo.