Por que um bom software leva tempo e não pode ser apressado

O Flask levou oito anos para chegar à versão 1.0. O SQLite está em desenvolvimento ativo desde 2000 e ainda recebe melhorias significativas. O kernel Linux tem mais de três décadas e, sem dúvida, está ficando melhor com a idade. Enquanto isso, de uma startup financiada por VC espera-se que mostre tração em 18 meses ou explique por que não.

Existe um descompasso crescente entre quanto tempo um bom software leva para ser construído de fato e quanto tempo esperamos que leve. A pressão para entregar rápido não está errada por natureza, mas cria uma cultura em que a paciência é vista como falta de ambição, e em que os projetos que perduram são descartados como “lentos” durante os anos em que estão silenciosamente acertando as coisas.

O Mito do Sucesso da Noite para o Dia

Quase todo “sucesso da noite para o dia” em software tem uma longa história por trás. O React foi usado internamente no Facebook por mais de um ano antes de ser open source. O Rust passou sete anos em desenvolvimento antes de chegar à 1.0. O PostgreSQL começou como projeto de pesquisa em 1986 e só se tornou o banco de dados de produção preferido na década de 2010, o que representa quase 30 anos de melhorias silenciosas e constantes.

O que parece uma emergência repentina geralmente é o resultado de melhorias acumuladas que cruzam um limiar de visibilidade. O software estava melhorando o tempo todo. As pessoas simplesmente não prestavam atenção até que ele ficasse bom o suficiente para ser inegável.

Armin Ronacher, criador do Flask, escreveu sobre isso diretamente. O Flask começou como uma brincadeira de 1º de abril em 2010. Tornou-se um projeto sério quase por acidente. Anos de trabalho incremental, corrigindo casos extremos, melhorando a documentação e repensando APIs, transformaram-no em um dos frameworks web Python mais populares. Nenhum desses anos foi desperdiçado. Cada um deles deixou a base mais forte.

Por que o Software Tem um Componente de Tempo Irredutível

Alguns problemas não podem ser resolvidos mais rápido adicionando mais pessoas ou trabalhando mais. Fred Brooks identificou isso em 1975 com The Mythical Man-Month, e a ideia central não mudou: certos aspectos do desenvolvimento de software são sequenciais, não paralelizáveis.

• Entender o domínio do problema. Você não consegue compreender totalmente um espaço de problema até ter convivido com ele por um tempo. A primeira versão de qualquer software codifica suas suposições iniciais. A segunda versão codifica o que você aprendeu com a primeira. Entendimento real exige iterações, e iterações levam tempo.
• Design e estabilidade de APIs. Boas APIs surgem do uso. Não dá para projetar uma API perfeita no vácuo: você precisa de usuários reais batendo em casos extremos reais. Bibliotecas que se apressam para a 1.0 costumam se arrepender das decisões de design iniciais por anos.
• Casos extremos e robustez. Os primeiros 80% de uma funcionalidade levam 20% do tempo. Os casos extremos restantes, o tratamento de erros e as peculiaridades de cada plataforma levam os outros 80%. Essa proporção não é preguiça, é a natureza fundamental de tornar um software confiável.
• Comunidade e ecossistema. Uma ferramenta não é realmente útil até ter documentação, tutoriais, plugins e uma comunidade que responda perguntas. Esse ecossistema não pode ser fabricado; ele cresce organicamente com o tempo.

O Custo da Urgência Artificial

“Move fast and break things” foi um lema razoável para uma rede social que buscava encontrar product-market fit. É uma filosofia péssima para infraestrutura, ferramentas de desenvolvimento, bancos de dados ou qualquer coisa da qual os sistemas de outras pessoas dependem. Quando você apressa softwares fundamentais, as quebras se acumulam.

Já vi vários projetos open source promissores implodirem porque tentaram crescer mais rápido do que suas bases conseguiam sustentar. O padrão é previsível: um projeto fica popular, os mantenedores sentem pressão para lançar funcionalidades rapidamente, a qualidade cai, os contribuidores se esgotam e os usuários migram para algo mais estável. A ironia é que desacelerar os teria levado mais longe.

Os projetos que duram não são os que foram entregues mais rápido. São os que tomaram boas decisões cedo o suficiente para não precisar reescrever tudo depois.

Dívida técnica não é só código bagunçado. Ela nasce de decisões tomadas sob pressão de tempo que restringem possibilidades futuras. Cada atalho para entregar mais rápido é um imposto sobre cada mudança futura. Alguns atalhos valem a pena, mas você deve tomá-los deliberadamente, não porque alguém decidiu arbitrariamente que o prazo é na próxima terça-feira.

Como é a Paciência na Prática

Paciência no desenvolvimento de software não significa avançar devagar por avançar. Significa ser deliberado sobre o que você constrói e honesto sobre quanto tempo as coisas levam. Alguns padrões que vejo funcionar bem:

• Lance cedo, mas comprometa-se devagar. Lance seu software para os usuários rapidamente para obter feedback, mas seja bem conservador sobre o que você assume como API estável. Use o versionamento 0.x com generosidade. Deixe claro que as coisas podem mudar.
• Diga não a funcionalidades. Cada funcionalidade que você adiciona é uma que você mantém para sempre. Os melhores projetos são opinativos sobre seu escopo. O SQLite lista explicitamente coisas que nunca fará, e essa disciplina é a razão de ser o banco de dados mais implantado do mundo.
• Invista em fundamentos. Documentação, testes, mensagens de erro e desempenho não são glamourosos, mas se acumulam. Um projeto bem documentado, com uma suíte de testes sólida, pode avançar mais rápido no terceiro ano do que um mal documentado no primeiro.
• Proteja a energia dos mantenedores. O esgotamento é o principal causador da morte de projetos open source. Ritmo sustentável importa mais que velocidade de sprint. Um mantenedor que trabalha 20 horas focadas por semana durante cinco anos entrega mais do que outro que trabalha 80 horas por semana durante seis meses e depois desaparece.

A Armadilha da Velocidade das Startups

Startups enfrentam uma tensão legítima: precisam se mover rápido para sobreviver, mas avançar rápido demais cria sistemas frágeis que se tornam um passivo conforme escalam. As empresas que lidam bem com isso tendem a distinguir dois tipos de velocidade.

Velocidade de iteração: quão rápido você consegue testar ideias, obter feedback dos usuários e mudar de direção. Essa deve ser maximizada. Ciclos curtos, prototipagem rápida e disposição para jogar coisas fora.

Velocidade de comprometimento: quão rápido você trava decisões de arquitetura, APIs públicas e modelos de dados. Essa deve ser minimizada. Mantenha as coisas reversíveis pelo máximo de tempo possível. Quanto mais você puder adiar decisões irreversíveis, mais informação terá quando finalmente as tomar.

O erro mais comum das startups é confundir as duas. Elas se comprometem com arquiteturas tão rápido quanto iteram em funcionalidades e, então, passam os dois anos seguintes pagando o imposto das decisões prematuras.

Aprendendo com Projetos que Duraram

Os projetos de software de que mais dependemos têm um traço em comum: em algum momento, todos foram considerados “lentos”. O PostgreSQL era a escolha sem graça enquanto o MySQL era a opção rápida e descuidada. O Python era “lento demais” enquanto o Perl era a escolha pragmática. O Git levou anos para se tornar utilizável por humanos comuns.

O que esses projetos tiveram foi tempo: tempo para cometer erros, aprender com eles e construir algo sólido. Eles não tentaram ser tudo para todos no primeiro ano. Tentaram ser excelentes em seu propósito central e estavam dispostos a deixar essa excelência levar o tempo que precisasse.

Da próxima vez que você ficar frustrado porque um projeto está “demorando demais”, considere que as coisas de que você mais depende (seu sistema operacional, seu banco de dados, seu runtime de linguagem, seu controle de versão) levaram mais tempo do que qualquer um esperava. E é exatamente por isso que funcionam.

Algumas coisas simplesmente levam tempo. A melhor resposta não é lutar contra essa realidade, e sim construir sistemas, equipes e expectativas que levem isso em conta.