| Bellacosa Mainframe e o estouro da bolha dotcom capitulo xi |
Capítulo XI — Das Cinzas Nasceu um Novo Jeito de Construir Software: Como a Bolha da Internet Criou as Startups Modernas, o Agile e a Cultura Lean
Por que o maior fracasso da primeira geração da Internet tornou-se a fundação da segunda geração da inovação tecnológica
"Os pioneiros constroem o caminho. Os sobreviventes aprendem onde estavam os buracos."
Existe uma frase muito conhecida na engenharia.
"Os sistemas mais robustos normalmente são construídos sobre os erros das versões anteriores."
Isso vale para software.
Vale para hardware.
Vale para aviões.
Vale para automóveis.
E vale perfeitamente para a Internet.
Quando a bolha das Dot-Com estourou, muita gente acreditou que o empreendedorismo tecnológico havia chegado ao fim.
Os investidores desapareceram.
As startups quebraram.
Os escritórios foram fechados.
Os jornais passaram a tratar a Internet com enorme desconfiança.
Mas algo curioso aconteceu.
Enquanto Wall Street enterrava a primeira geração das empresas digitais, engenheiros e empreendedores estavam estudando cuidadosamente tudo o que havia dado errado.
Essa talvez tenha sido a maior herança da bolha.
Ela ensinou.
E ensinou muito.
Foi justamente desse aprendizado que nasceu praticamente toda a cultura de desenvolvimento moderno que conhecemos hoje.
O Fim da Filosofia "Construa Primeiro, Pense Depois"
Durante os anos da bolha existia uma mentalidade bastante comum.
Lançar rapidamente.
Ganhar usuários.
Corrigir problemas depois.
Essa estratégia parecia funcionar enquanto existia dinheiro abundante.
Mas quando o capital desapareceu...
Muitos descobriram que haviam construído sistemas enormes sobre fundações frágeis.
Projetos difíceis de manter.
Infraestruturas caras.
Código praticamente impossível de evoluir.
A indústria compreendeu que velocidade sem direção produz apenas acidentes mais rápidos.
Surge uma Nova Pergunta
Antes da bolha, muitos empreendedores perguntavam:
"Como posso crescer mais rápido?"
Depois da crise, a pergunta mudou completamente.
"Como descubro rapidamente se minha ideia realmente faz sentido?"
Pode parecer apenas uma mudança de palavras.
Na realidade...
Mudou toda a filosofia de desenvolvimento de produtos.
Em vez de investir milhões antes de validar uma hipótese...
Passou-se a testar primeiro.
Aprender rapidamente.
Corrigir.
Evoluir.
O Nascimento da Cultura Lean
Embora suas origens estejam na indústria automobilística japonesa, especialmente no Sistema Toyota de Produção, foi após a bolha da Internet que muitos desses princípios começaram a ser adaptados para startups de tecnologia.
Eliminar desperdícios.
Construir apenas o necessário.
Aprender continuamente.
Melhorar processos.
Entregar valor.
Esses conceitos tornaram-se extremamente populares.
Anos depois surgiria o movimento conhecido como Lean Startup, consolidado por Eric Ries.
Seu princípio central parecia quase revolucionário.
Não construa um produto completo antes de descobrir se alguém realmente precisa dele.
Hoje isso parece óbvio.
Em 1999 não era.
MVP: O Produto Mínimo Viável
Outro conceito que ganhou enorme importância foi o famoso Minimum Viable Product, ou MVP.
A ideia é simples.
Em vez de gastar anos desenvolvendo uma solução perfeita...
Crie uma versão pequena.
Teste com clientes reais.
Aprenda.
Corrija.
Repita.
Essa filosofia reduziu drasticamente o desperdício de tempo e dinheiro.
Empresas passaram a descobrir problemas muito antes de investir milhões em projetos inviáveis.
Em certo sentido...
O MVP tornou-se uma vacina contra muitas das doenças que destruíram as Dot-Com.
O Cliente Tornou-se Parte do Desenvolvimento
Durante a bolha era relativamente comum desenvolver produtos imaginando aquilo que os clientes desejariam.
Após a crise...
As empresas passaram a perguntar diretamente aos usuários.
Entrevistas.
Testes.
Protótipos.
Versões beta.
Feedback contínuo.
O cliente deixou de aparecer apenas no final do projeto.
Passou a participar desde o início.
Essa mudança alterou completamente a engenharia de produtos digitais.
Agile: Responder às Mudanças
Em 2001, praticamente no auge das consequências da bolha, um grupo de desenvolvedores reuniu-se em Snowbird, Utah.
Dessa reunião nasceu o famoso Manifesto Ágil.
Embora suas ideias não tenham surgido exclusivamente por causa da bolha, o contexto histórico teve enorme influência.
Os profissionais estavam cansados de projetos gigantescos que demoravam anos para entregar resultados.
O mercado precisava de adaptação.
Flexibilidade.
Entrega contínua.
Colaboração.
Assim surgiram princípios que hoje fazem parte do cotidiano de praticamente toda empresa de software.
O Manifesto Ágil Não Era Contra Planejamento
Existe um equívoco bastante comum.
Muitas pessoas acreditam que Agile significa ausência de planejamento.
Não significa.
O Manifesto Ágil nunca afirmou isso.
Ele apenas reconheceu que planos precisam evoluir conforme aprendemos mais sobre o problema.
É uma diferença enorme.
Planejar continua sendo essencial.
Mas o plano deixa de ser um documento imutável.
Passa a ser uma ferramenta viva.
Scrum, Kanban e a Nova Organização das Equipes
Poucos anos depois começaram a popularizar-se metodologias como:
Scrum.
Kanban.
Extreme Programming.
Crystal.
Feature Driven Development.
Cada uma com características próprias.
Todas compartilhando uma mesma filosofia.
Aprender continuamente.
Entregar valor frequentemente.
Corrigir rapidamente.
Evitar desperdícios.
Essas ideias transformaram completamente a maneira como software passou a ser desenvolvido.
DevOps: Derrubando Muros
Outro aprendizado importante surgiu da dificuldade de colocar sistemas em produção.
Durante muitos anos existia uma separação rígida.
Os desenvolvedores criavam o software.
A equipe de operações mantinha os servidores.
Quando algo dava errado...
Cada grupo culpava o outro.
A partir da década seguinte ganhou força o conceito de DevOps.
Desenvolvimento e Operações trabalhando juntos.
Automação.
Monitoramento.
Entrega contínua.
Responsabilidade compartilhada.
Foi mais uma consequência indireta da necessidade de construir sistemas mais confiáveis.
A Cultura da Medição
Outra transformação importante ocorreu na maneira como empresas passaram a tomar decisões.
Antes da bolha muitas estratégias eram baseadas principalmente em expectativas.
Depois dela...
Começou a crescer a cultura dos indicadores.
Métricas.
Dashboards.
KPIs.
Testes A/B.
Análises estatísticas.
As empresas passaram a medir praticamente tudo.
Tempo de resposta.
Conversão.
Retenção.
Disponibilidade.
Latência.
Uso de memória.
Custos.
A intuição continuava importante.
Mas agora caminhava ao lado dos dados.
Enquanto Isso... O Mainframe Apenas Chamava Isso de Rotina
Para um profissional de mainframe, muitos desses conceitos parecem familiares.
Medição?
Sempre existiu.
SMF.
RMF.
Relatórios de desempenho.
Planejamento de capacidade.
Disponibilidade.
Auditoria.
Mudanças controladas.
Recuperação.
Observabilidade.
Muito antes de existirem dashboards coloridos em aplicações web, administradores de sistemas IBM Z já acompanhavam detalhadamente o comportamento de seus ambientes.
Talvez por isso muitos veteranos olhem para DevOps não como uma revolução absoluta.
Mas como uma evolução natural de princípios antigos aplicados a novos ambientes.
O Fracasso Tornou-se Professor
Existe outra mudança cultural extremamente interessante.
Antes da bolha, fracassar era visto como vergonha.
Depois dela...
Começou a surgir uma visão diferente.
Fracassar rapidamente pode ser melhor do que insistir durante anos em uma ideia inviável.
É importante compreender corretamente essa filosofia.
Ela nunca significou:
"Fracasse por qualquer motivo."
Significava:
"Aprenda rapidamente quando algo não funciona."
Essa diferença é enorme.
A Engenharia Voltou a Liderar
Após anos de excesso de marketing, o mercado voltou a valorizar profundamente engenheiros.
Arquitetos.
Especialistas em banco de dados.
Profissionais de infraestrutura.
Especialistas em segurança.
SREs.
DBAs.
Administradores de sistemas.
Todos passaram a ocupar posição estratégica.
As empresas perceberam algo fundamental.
Não basta convencer investidores.
É preciso construir sistemas capazes de sobreviver.
O Paralelo com a Inteligência Artificial
Estamos vivendo novamente um momento de enorme experimentação.
Modelos surgem diariamente.
Frameworks aparecem toda semana.
Ferramentas mudam rapidamente.
Nesse cenário, conceitos como MVP, Agile e Lean tornam-se ainda mais importantes.
Não faz sentido investir milhões em uma solução de IA sem validar primeiro se ela realmente resolve o problema do cliente.
A velocidade continua importante.
Mas o aprendizado tornou-se ainda mais importante.
A Evolução Nunca Para
Curiosamente, muitas ideias consideradas revolucionárias hoje provavelmente parecerão comuns daqui a vinte anos.
Assim como Agile evoluiu.
Assim como DevOps evoluiu.
Assim como Cloud evoluiu.
Também veremos novas formas de desenvolver software impulsionadas pela Inteligência Artificial.
Entretanto...
Os princípios continuarão praticamente os mesmos.
Aprender.
Adaptar.
Melhorar continuamente.
Lições para o Padawan COBOL
Existe uma sabedoria silenciosa presente nos grandes sistemas corporativos.
Eles raramente são reconstruídos do zero.
Eles evoluem.
Recebem novos módulos.
Novas interfaces.
Novos bancos de dados.
Novas APIs.
Novas integrações.
Essa mentalidade é muito próxima da filosofia Lean.
Melhoria contínua.
Evolução incremental.
Valor entregue constantemente.
No universo da Frota Estelar, os engenheiros da Enterprise não desmontam completamente a nave a cada nova missão. Eles atualizam sensores, substituem componentes, aprimoram motores e instalam novos sistemas, preservando aquilo que já demonstrou ser confiável.
A indústria de software aprendeu exatamente essa lição depois da bolha da Internet.
Não é preciso destruir tudo para inovar.
É preciso construir sobre bases sólidas.
Foi essa mudança de mentalidade que preparou o terreno para a computação em nuvem, os smartphones, os microsserviços, o DevOps moderno e, décadas mais tarde, a Inteligência Artificial.
No próximo capítulo veremos como todas essas transformações acabaram aproximando dois mundos que durante muito tempo pareciam opostos: o universo das startups e o universo do mainframe. Descobriremos que, apesar das diferenças aparentes, ambos passaram a compartilhar exatamente os mesmos objetivos: escalabilidade, disponibilidade, segurança, automação e evolução contínua.
Sem comentários:
Enviar um comentário