Primeiro faça funcionar, depois faça direito, depois faça melhor
Engenheiros debatem o mantra popular de “primeiro faça funcionar, depois faça direito, depois faça mais rápido”, equilibrando prototipagem rápida e MVPs com os custos de longo prazo da dívida técnica e de erros arquiteturais. Muitos argumentam que desempenho, acessibilidade e manutenibilidade devem ser considerados mais cedo do que o slogan sugere, citando exemplos como apps baseados em Electron e gambiarras “temporárias” que se tornam permanentes. Outros contrapõem que, na maioria dos contextos comerciais, lançar algo “bom o suficiente” rapidamente é racional, porque muitos produtos nunca sobrevivem tempo suficiente para justificar uma reescrita completa ou uma otimização profunda.
Interpretações do mantra
- Muitas variações são propostas:
- “Faça funcionar, faça direito, faça rápido.”
- “Faça possível → agradável/provável → lucrativo/barato.”
- “Faça rodar → faça direito → faça rápido (se necessário).”
- “Faça funcionar → funcione bem → fique bonito.”
- Vários კომენტários argumentam que “direito” e “rápido” costumam estar interligados; escolhas centrais de API e estrutura de dados podem travar o desempenho, forçando quase-reescritas depois.
- Outros veem “rápido” como uma etapa distinta, posterior, viabilizada por uma API limpa e estável que permita trocar implementações sem mudar o comportamento.
Correção, desempenho e arquitetura
- Muitos enfatizam a correção primeiro: um programa rápido que produz resultados errados é inútil.
- Alguns afirmam que a maioria dos problemas de desempenho é local (consultas, funções) e pode ser corrigida sem rearquitetura.
- Outros insistem que o desempenho moderno é em grande parte arquitetural; se você não projetar para eficiência cedo, a “otimização” posterior vira uma reescrita.
MVP, iteração e “bom o suficiente”
- Há forte apoio a “lançar rápido, iterar rápido”: a primeira versão descobre o problema real; passagens posteriores refinam e otimizam.
- Críticos observam que código de “protótipo” ou “temporário” raramente é descartado; remendos se tornam permanentes por pressão comercial e priorização.
- Vários enfatizam que software atende necessidades de negócio; se algo é “bom o suficiente” para clientes e receita, reescritas profundas são difíceis de justificar.
Electron e uso de recursos
- Electron é usado como estudo de caso central:
- Lado pró-Electron: enorme base de desenvolvedores, paridade multiplataforma e rapidez de desenvolvimento frequentemente superam os custos de RAM/CPU; empresas otimizam para velocidade e viabilidade.
- Lado anti-Electron: é desperdiçador, empurra custos de hardware/energia para os usuários, especialmente prejudicial para apps sempre em execução (chat, música).
- Alguns argumentam que os usuários em geral carecem mais de melhores opções ou compreensão do que de falta de preocupação.
Processo, refatoração e risco
- Vários defendem ciclos explícitos: prototipar, depois “fazer direito”, depois “fazer melhor”, às vezes com uma regra deliberada de “jogar fora o primeiro rascunho”.
- Outros alertam que, sem tempo, autoridade e cultura para refatorar, os passos 2 e 3 nunca acontecem.
- Conceitos como decisões reversíveis vs. irreversíveis e “último momento responsável” são mencionados como ferramentas para decidir quando investir em “fazer direito” versus “só lançar”.