O desenvolvimento de software está repleto de estruturas familiares—Ágil, Cascata, Scrum—todas escolhas sólidas que ajudam as equipas a entregar atempadamente e com menos surpresas.
Mas, por vezes, ficamos tão confortáveis a seguir estes caminhos já muito percorridos que nos esquecemos de que os verdadeiros avanços acontecem frequentemente quando alguém experimenta algo que, no papel, parece absurdo. É arriscado, sem dúvida, mas é geralmente aí que se escondem os grandes êxitos.
“A AI é realmente muito boa a fazer 70% do trabalho mais depressa”, afirma Alex Zajac, SDE & AI na Amazon e criador da newsletter Hungry Minds. “Mas esses 30% finais são os mais difíceis—colocá-la em produção, garantir que não alucina e configurar barreiras de avaliação.”
Por outras palavras, o desenvolvimento de software arrojado não consiste apenas em utilizar ferramentas novas—trata-se de fazer o trabalho difícil e pouco glamoroso de as fazer funcionar realmente.
A maioria das empresas mantém o manual habitual porque este é visto como “seguro”. Ninguém é responsabilizado por seguir um caminho diferente se uma ideia não resultar num processo padrão. No entanto, de acordo com um inquérito da McKinsey de 2023, as empresas que incentivam a assunção calculada de riscos têm 1.7x mais probabilidades de superar os seus pares do setor nos indicadores de inovação.
E mesmo quando sabemos que o pensamento arrojado pode compensar, é surpreendentemente raro encontrar ambientes que recompensem verdadeiramente a experimentação. São poucas as organizações que incentivam explicitamente a assunção de riscos em projetos de software.
Os primeiros a adotar, ou por vezes verdadeiros pioneiros, conseguem frequentemente definir as regras antes de todos os outros sequer saberem que elas existem.
Apesar de todo o medo e hesitação, existem equipas que deram um salto de fé e encontraram algo brilhante. Eis cinco estratégias que inicialmente pareciam pouco convencionais—ou talvez demasiado caóticas—para terem sucesso.
Estratégia n.º 1: Engenharia do Caos (Netflix)
O “Chaos Monkey” da Netflix danifica intencionalmente os sistemas em produção para testar a resiliência. Parece uma loucura, não é? Mas esta abordagem ajudou a Netflix a manter uma disponibilidade de 99.99% enquanto crescia de 7 milhões para mais de 230 milhões de subscritores.
“Percebemos que esperar pela estabilidade não era uma estratégia”, afirmou Kolton Andrus, antigo engenheiro da Netflix. “Ao injetarmos falhas regularmente, as nossas equipas deixaram de temer as interrupções e construíram sistemas mais robustos por predefinição.”
A principal conclusão era contraintuitiva: criar falhas controladas impedia, na verdade, as falhas catastróficas. Os testes de injeção de falhas da Netflix revelaram fragilidades que teriam permanecido ocultas até ocorrer uma grande interrupção.
Conclusão prática: Comece com um “Dia de Jogo” em que simula falhas num ambiente que não seja de produção. Escolha um serviço crítico e introduza falhas simples, como terminar instâncias ou interromper ligações de rede. Documente aquilo que falhar e corrija essas vulnerabilidades antes que causem problemas reais.
Have an account? Log In
Estratégia n.º 2: Implementação contínua (Flickr)
Em 2009, quando a maioria das empresas fazia implementações mensais, a apresentação do Flickr sobre “10 implementações por dia” deixou todos boquiabertos. As equipas receavam que lançamentos menores e frequentes criassem o caos, mas o Flickr descobriu o oposto: lançamentos mais frequentes reduziam efetivamente o risco de forma drástica.
A matemática é simples, mas poderosa: se implementar 5-10 alterações de cada vez, é fácil isolar os problemas. Se implementar 500 alterações ao fim de um mês, boa sorte a encontrar a agulha nesse palheiro.
Lote menor de implementações = menor raio de impacto.
As empresas que adotam a CD registam menos 70% de falhas em produção e uma recuperação 24 vezes mais rápida quando ocorrem problemas, de acordo com o relatório Estado do DevOps de 2023. Desde então, esta prática tornou-se padrão em empresas tecnológicas de todas as dimensões.
Conclusão prática: Implemente uma abordagem de “janela de implementação” em que as equipas aumentam gradualmente a frequência das implementações. Comece por passar de implementações mensais para semanais e, depois, duas vezes por semana, até criar a automatização e a confiança necessárias para implementar várias vezes por dia. Concentre-se em criar um conjunto robusto de testes que seja executado automaticamente antes de cada implementação.
Estratégia n.º 3: Modelo totalmente remoto (GitLab)
Antes da pandemia, a estrutura totalmente remota do GitLab parecia radical. No entanto, permitiu à empresa contratar os melhores talentos a nível global e obrigou à adoção de excelentes práticas de documentação desde o primeiro dia.
O manual público do GitLab (agora com mais de 15 000 páginas) tornou-se a sua arma secreta, eliminando o problema do «eu não sabia disso» que afeta muitas equipas distribuídas. Esta abordagem centrada na documentação permitiu que os novos colaboradores se integrassem mais rapidamente e tornou a tomada de decisões mais transparente.
A documentação é mais escalável do que o conhecimento tribal. Pense em grande!
«Quando não podemos tocar no ombro de alguém para obter informações, somos obrigados a documentar tudo claramente», explica Darren Murph, responsável pelo trabalho remoto no GitLab. «Isto cria uma resiliência organizacional que as empresas centradas no escritório raramente conseguem alcançar.»
Conclusão prática: Mesmo que não trabalhe totalmente à distância, adote uma prática de documentação «remota por princípio». Crie uma base de conhecimento centralizada para todas as decisões, processos e conhecimentos tribais importantes. Estabeleça uma regra segundo a qual, se algo não estiver documentado, não existe. Reveja esta documentação trimestralmente para a manter atualizada.
Estratégia n.º 4: Desenvolvimento baseado no tronco (Etsy)
A Etsy abandonou estratégias complexas de ramificação em favor de um modelo em que todos fazem frequentemente commits para a base de código principal. Esta abordagem pôs em causa a ideia convencional de que os programadores precisam de ramificações de funcionalidades isoladas para trabalharem eficazmente.
«Descobrimos que as ramificações de longa duração criavam uma falsa sensação de segurança», afirma o antigo engenheiro da Etsy Daniel Schauenberg. «Na realidade, apenas adiavam os problemas de integração e criavam conflitos maiores quando as ramificações finalmente eram integradas.»
O desenvolvimento baseado no tronco ajudou a Etsy a crescer de 50 para mais de 2 000 programadores, continuando a implementar alterações mais de 50 vezes por dia. Esta abordagem obrigou a equipa a criar melhores testes automatizados, uma vez que a ramificação principal tinha de se manter limpa, e eliminou o tão comum «inferno das fusões» que as equipas enfrentam com ramificações de funcionalidades.
Alex assinalou um padrão semelhante ao falar sobre IA e bases de código com muito contexto. “As coisas que estão realmente profundamente acopladas aos seus sistemas proprietários… exigirão muitas pessoas”, afirmou.
Em ambientes de evolução rápida, as equipas que trabalham diretamente no tronco precisam de compreender profundamente o desenho do sistema e as relações de compromisso — porque há menos espaço para se esconderem atrás de ramificações de longa duração. Não se trata apenas de fazer commits de código mais rapidamente; trata-se de os engenheiros estarem mais próximos da verdadeira complexidade.
Conclusão prática: Implemente sinalizadores de funcionalidades para ocultar o trabalho em curso enquanto faz commits diários para a ramificação principal. Comece com uma equipa pequena e de confiança para criar segurança na abordagem. Defina como objetivo da equipa fazer commit para a ramificação principal pelo menos uma vez por dia e meça a redução dos problemas de integração ao longo do tempo.
A sua estratégia para os sinalizadores de funcionalidades é realmente importante para o que mostra aos seus clientes!
More Articles
Estratégia n.º 5: Código aberto por defeito (Hashicorp)
A Hashicorp criou uma empresa avaliada em mil milhões de dólares ao disponibilizar como código aberto as suas principais ferramentas de infraestrutura, como o Terraform, o Vault e o Consul. Ao contrário dos modelos tradicionais de negócio de software, esta estratégia permitiu uma adoção rápida e contribuições de milhares de programadores em todo o mundo.
«Quando começámos, as pessoas achavam que éramos loucos por oferecermos o nosso melhor código», observa Mitchell Hashimoto, cofundador. «Mas descobrimos que uma adoção generalizada cria mais valor do que aquilo que se perde em potenciais receitas de licenciamento.»
Para os programadores individuais, a escolha das ferramentas melhoradas por IA adequadas pode seguir uma lógica semelhante. Alex partilhou que decidiu recentemente comprar o Cursor Pro porque “simplesmente me compreende ou compreende o estilo com que estou a trabalhar.” Tal como a HashiCorp apostou na confiança e na adequação à comunidade com o código aberto, os engenheiros estão agora a inclinar-se para ferramentas que compreendem intuitivamente os seus fluxos de trabalho — mesmo quando isso implica escolher a opção menos generalizada.
A sua ferramenta Terraform obteve mais de 100 000 estrelas no GitHub e tornou-se um padrão do setor — algo que teria levado décadas com uma abordagem tradicional de código fechado. A empresa monetiza através de funcionalidades empresariais, suporte e serviços alojados, mantendo simultaneamente a boa vontade de uma enorme comunidade de programadores.
Conclusão prática: Identifique os componentes do seu software que poderiam beneficiar do envolvimento da comunidade. Comece por disponibilizar como código aberto uma biblioteca ou ferramenta útil que não faça parte da sua propriedade intelectual principal. Crie um processo de contribuição que facilite a melhoria do seu código por parte de pessoas externas e invista numa boa documentação para facilitar a adoção.
O fio condutor
O que liga estas estratégias não é apenas a ousadia — é o risco calculado com ciclos de feedback rápidos. Cada equipa criou mecanismos para aprender rapidamente com os erros e corrigir o rumo.
Alex mencionou como a IA está a alterar o que significa ser programador. “Não estamos a ser substituídos”, afirma, “mas a janela móvel de responsabilidade está a mudar.”
Alguns dizem que os programadores estão a tornar-se mais semelhantes a engenheiros de produto; outros preveem uma bifurcação entre generalistas e especialistas. Seja como for, as estratégias ousadas de desenvolvimento da atualidade não têm sucesso apenas devido às ferramentas inovadoras — têm sucesso quando as equipas estão dispostas a adaptar os seus fluxos de trabalho, funções e forma de pensar.
Ao repensar as suas estratégias de desenvolvimento, encontrar os parceiros certos pode fazer toda a diferença. Pode, por exemplo, considerar trabalhar com uma empresa de desenvolvimento de software personalizado ou com uma empresa de desenvolvimento de software de proximidade, por exemplo.
Subscreva o boletim informativo do The CTO Club para obter mais dicas, ferramentas e melhores práticas de desenvolvimento de software.
