- A opacidade dos sistemas de grandes empresas de tecnologia
- Grandes empresas de tecnologia operam até mesmo seus próprios sistemas em uma espécie de "névoa de guerra (fog of war)".
- Mesmo perguntas básicas como "Usuários do tipo Y podem usar o recurso X?", "O que exatamente acontece na ação Z?" e "Quantos planos existem atualmente?" só podem ser respondidas por poucas pessoas dentro da organização.
- Em casos mais graves, é preciso designar alguém exclusivamente para investigar, embora a resposta devesse estar evidente apenas pela documentação pública — mas não está.
- A origem da complexidade: Wicked Features
- Softwares grandes se tornam extremamente complexos por causa de self-hosting, teste gratuito, controles de organização/políticas, localização multilíngue, recursos de conformidade regulatória etc. Esses recursos afetam todos os novos recursos.
- Ex.: ao adicionar controle por políticas, ele precisa ser aplicado a cada novo recurso; ao localizar um produto, as traduções também precisam acompanhar.
- Perguntas como "um cliente enterprise com self-hosting na região da UE pode acessar determinado recurso?" só podem ser verificadas explorando diretamente o código ou por experimentação. Omitir esse tipo de recurso significa abrir mão de uma enorme receita, e isso diferencia empresas grandes das pequenas.
- Os limites da documentação
- Em teoria, seria possível documentar as interações ao lançar novos recursos, mas o sistema muda mais rápido do que a documentação.
- Em um ambiente dinâmico, e não estático, quem escreve documentação teria de estar sempre à frente das mudanças, algo praticamente impossível.
- Um problema ainda maior: muitos comportamentos surgem não de intenção explícita, mas da interação entre configurações padrão — documentar isso se torna parecido com explorar o sistema real.
- O cerne da resposta: o codebase e os engenheiros
- Respostas precisas só surgem ao olhar diretamente para o codebase, e isso é a base do poder dos engenheiros.
- A função central de uma equipe de engenharia é a capacidade de responder a perguntas sobre o software.
- Isso envolve usar conhecimento tácito que vive na cabeça de quem conhece determinado código.
- Quando há reorganizações de equipe, a perda desse conhecimento exige uma espécie de "cirurgia exploratória" (forçar mudanças no código, adicionar verificações etc.).
- Escrever código é fácil, mas dar respostas confiáveis é difícil por uma questão de confiança (risco de errar, necessidade de resumir e comprimir informação).
- Conclusão: uma capacidade valiosa
- Pessoas não técnicas acreditam que o software é perfeitamente compreendido pelos engenheiros, mas ninguém entende perfeitamente sistemas grandes.
- Até perguntas básicas exigem investigação repetida, e mudanças introduzem nuances e exceções. A capacidade de dar respostas precisas é extremamente valiosa.
Ainda não há comentários.