Traduzido do original The Start-Up Trap com autorização da The 8th Light. A tradução não foi revisada pelo autor, Uncle Bob Martin.

  • Você entrou em uma nova startup.
  • Você é um mega-ser multi-talentoso.
  • Você pode trabalhar 60, 70, 80 horas por semana para fazer seu trabalho.
  • Você é um programador e arquiteto de alto nível.
  • Você não vai cair nas arapucas que outros caíram.
  • Você terá certeza que desta vez será diferente.
  • Você é tão bom que as regras não valem para você.
  • Você está fodido.

A Arapuca da Startup

É uma história triste que temos visto e revisto. Um jovem programador começa com as melhores das intenções, aprende todas as disciplinas certas, desenvolve todas as habilidades certas, para então cair nas garras d’A Arapuca da Startup. A Arapuca da Startup é a ideia de que sua situação é diferente, de que tudo o que você aprendeu sobre como fazer software direito, de alguma forma, não se aplica a este trabalho específico. Você acha que isso vai valer mais tarde, quando você for bem-sucedido. Mas não agora. Ainda não. Não enquanto você estiver na corrida pelo sucesso.

É uma cilada, Bino!

A Arapuca da Startup é o pensamento de que a fase de startup é diferente; e que, enquanto você está nessa fase, o sucesso depende de quebrar as regras. Isso é burrice. A fase de startup não é diferente. Essa fase é apenas a primeira de muitas outras fases, e que vai definir o tom de todas as outras fases. Volte àquela empresa depois de cinco anos e eles (caso tenham conseguido sobreviver) ainda irão manter a mesma atitude em relação às regras que tinham na primeira fase – exceto, talvez, para as horas extras (risos).

Aqui vai uma pequena dica: as disciplinas que levam ao software de sucesso são sempre válidas, não importa em qual fase a companhia está. É risível pensar que boas disciplinas são menos importantes durante o estágio de startup. A verdade é que, na fase de startup, essas disciplinas são tão críticas quanto em outros momentos.

É claro que uma das disciplinas que estou falando é Test Driven Development (TDD). Qualquer um que acha que pode ir mais rápido não escrevendo testes está fumando algumas drogas bem sérias. Oh, eu sei que você é um deus-guerreiro. Sei que você pode escrever código perfeito sempre. Sei que o prazo está acabando e você simplesmente não tem tempo para escrever testes. Sinto muito pelas suas falhas iminentes. Sinto por você estar lento e não saber disso ainda. Eu vou sentir muito quando você finalmente abrir caminho para um pouquinho de sucesso, creditar isso ao seu mau comportamento e recomendar isso para outros. Que Deus nos ajude, porque você não será ajudado.

Pergunte a si mesmo: como é que o gestor do dinheiro da startup se comporta? Essa pessoa é responsável por gerir o dinheiro dos investidores. Você acha que ele tem prazos? Acha que ele está sofrendo pressão para entregar projeções, previsões, relatórios de fluxo de caixa etc? Você acha que os chefes vão tolerar deslizes na sua agenda de obrigações? Vou te dizer agora que o cara que administra o dinheiro está sofrendo uma pressão infernal, mais do que qualquer desenvolvedor de software está.

Então como esse gestor se comporta? Será que ele verifica seu trabalho? Será que ele checa cuidadosamente a contabilidade? Será que ele segue todas as regras e disciplinas? Ou para ele as regras são diferentes pois ele está na fase de startup?

E se fosse a sua empresa? O seu dinheiro? O que você pensaria se o gestor do dinheiro da startup não verificasse os montantes, que negligenciasse o lado dos débitos da contabilidade e confiasse a saúde financeira da sua companhia apenas no lado das quantias de crédito?

Você atiraria nele! Atiraria tão rápido que o que sobrasse dele seria posto pra fora contando que o caminhão de lixo levasse embora!

Seu código é menos importante que as planilhas desse gestor? Os erros no código são mais toleráveis do que erros nessas planilhas? Podem os erros no código atrapalhar a companhia e arruinar sua reputação com os clientes, com os investidores? Você sabe responder essas perguntas. E você sabe disso: se os gestores do dinheiro acham um jeito de exercer suas disciplinas na startup, você também pode.

O desleixo no TDD vai ajudá-lo a ir mais rápido? Citando o Capitão Sulu quando a lua Klingon de Praxis é destruída e um jovem tenente pergunta se eles devem notificar a Starfleet: “Você tá brincando?” VOCÊ TÁ BRINCANDO?

Não, você não está indo rápido. Você está indo devagar. Os motivos são simples e você já os conhece. Você está caminhando devagar pois não será capaz de refazer. O código vai apodrecer, e rápido. Vai ficar mais e mais difícil de gerenciar. E você vai ficar lento.

Você não vai notar isso no começo pois ele parece rápido. Você está trabalhando bastante e gastando 60, 70, 80 horas por semana no código. O esforço que você está fazendo é enorme e isso parece rápido.

Mas esforço e velocidade não tem relação. É fácil gastar uma enorme quantidade de esforço e não fazer nenhum progresso. Inclusive, é fácil despender um esforço gigantesco e regredir. Esforço não é igual a velocidade e nem direção.

Conforme o tempo passar suas estimativas vão aumentar. Você vai ver que será mais e mais difícil adicionar novas funcionalidades. Você verá mais e mais bugs acumulados. Você irá separar os bugs em críticos e aceitáveis (como se um bug qualquer fosse aceitável!). Vai criar módulos tão frágeis que você não confiará em si mesmo, ou em qualquer um, para modificá-los, então você vai trabalhar em torno deles. Você vai empilhar códigos podres que, com o passar das semanas, vão exigir mais e mais esforço para continuar rodando. O progresso será lento e hesitante. Ele até poderá ser um regresso quando cada release ficar mais e mais bugado, e menos e menos estável. Catástrofes serão tão comuns quanto erros, que nunca deveriam acontecer, levando a corrompimentos e danos que precisarão de muito tempo para consertar.

Você conhece a história. Você sabe que é onde outros caíram. Se você é mais velho, provavelmente já caiu nessa uma ou duas vezes. E mesmo assim A Arapuca da Startup continua com o canto da sereia, atraindo você lentamente para comportamentos destrutivos e catastróficos.

Se você quer ir rápido. Se você quer ter as melhores chances de cumprir seus prazos. Se você quer a melhor chance de sucesso. Então não posso dar outro conselho melhor que este: seja disciplinado! Escreva seus testes. Refaça seu código. Mantenha as coisas simples e limpas. Não tenha pressa! O sangue da sua startup passa pelas suas mãos. Não seja negligente!

Lembre-se: a única forma de ir mais rápido é fazendo direito.

Autor: Uncle Bob Martin, da The 8th Light