Recentemente, o mundo da tecnologia foi surpreendido com a descoberta de um novo "Easter egg" num software bastante antigo: o Office 97. Esta funcionalidade escondida, que podia ser ativada através de um método bastante complexo, revelava um ecrã de créditos com a equipa de desenvolvimento e o famoso Clippy a fazer piadas. Embora esta descoberta tenha deliciado muitos fãs nostálgicos, levanta uma questão pertinente: porque é que a gigante tecnológica deixou de incluir estas brincadeiras no seu software moderno, especialmente no Windows?
A resposta envolve uma mistura de segurança, contratos governamentais e a evolução dos processos de desenvolvimento de software.
A iniciativa da Computação de Confiança
A mudança de paradigma começou em 2002, quando Bill Gates, então CEO da Microsoft, lançou a iniciativa "Trustworthy Computing" (TwC). Esta campanha surgiu como resposta às críticas dos clientes sobre as vulnerabilidades de segurança nos produtos da empresa. O objetivo era focar em pilares como a segurança, privacidade, fiabilidade e integridade empresarial.
Na prática, isto significava que o software deveria ser seguro desde a sua conceção. Para tal, era obrigatório que o código fosse bem escrito, totalmente documentado e facilmente auditável. Por definição, os Easter eggs são elementos ocultos ativados por ações não documentadas. A exigência de documentar cada linha de código acabou por eliminar estas surpresas em produtos como o Windows e o Office, uma vez que a empresa continua a considerar a TwC um marco vital na segurança do software.
Contratos governamentais e agências federais
Outro fator decisivo prende-se com a base de clientes da empresa. Embora existam versões ligeiramente diferentes do software para governos e agências federais, a base é essencialmente a mesma, diferindo apenas em funcionalidades de segurança. Estes são clientes empresariais altamente sensíveis, com os quais são assinados acordos de confidencialidade e contratos rigorosos sobre a fiabilidade do software.
A empresa simplesmente não pode arriscar esconder elementos imprevisíveis nos produtos que vende a estas entidades. Como as agências governamentais não auditam cada linha de código que compram, o aparecimento de algo inesperado — apenas porque um programador achou que seria divertido — levantaria questões sérias sobre o que mais poderia estar oculto e se violaria regulamentos governamentais. De facto, alguns organismos exigem que os fornecedores confirmem a inexistência de funcionalidades não documentadas nos seus produtos.
Mudanças nos paradigmas de programação e testes
Não se trata apenas de política, mas também da evolução do ciclo de vida do desenvolvimento de software. Com o crescimento da empresa ao longo dos anos — contando atualmente com cerca de 225.000 funcionários —, as equipas que trabalham nos produtos principais tornaram-se muito maiores. Existem grupos dedicados exclusivamente ao desenvolvimento, testes, auditoria e conformidade, garantindo que os produtos estão aptos para uso comercial.
Práticas modernas como a programação em pares, testes automatizados e pipelines de CI/CD (Integração Contínua/Entrega Contínua) com melhor visibilidade do código significam que há muito pouca probabilidade de comportamentos não documentados passarem despercebidos. Além disso, muitos produtos, como o Azure, possuem certificações ISO. Estas certificações de qualidade exigem que o código seja exaustivamente documentado para que qualquer problema possa ser facilmente rastreado até à sua origem.
Embora fosse divertido descobrir estes segredos, a imprevisibilidade inerente aos Easter eggs introduz riscos e potenciais violações de conformidade que, no cenário tecnológico atual, são simplesmente inaceitáveis.
Nenhum comentário
Seja o primeiro!