First do it, then do it right, then do it better
Engineers debate the popular mantra of “first make it work, then make it right, then make it fast,” weighing rapid prototyping and MVPs against the long-term costs of technical debt and architectural mistakes. Many argue that performance, accessibility and maintainability must be considered earlier than this slogan suggests, citing examples like Electron-based apps and “temporary” hacks that become permanent. Others counter that in most commercial settings, shipping something “good enough” quickly is rational, because many products will never survive long enough to justify a full rewrite or deep optimization.
Interpretations of the mantra
- Many variations are offered:
- “Make it work, make it right, make it fast.”
- “Make it possible → pleasant/probable → profitable/cheap.”
- “Make it run → make it right → make it fast (if needed).”
- “Make it work → work well → look good.”
- Several commenters argue that “right” and “fast” are often intertwined; core API and data-structure choices can hard‑lock performance, forcing near-rewrites later.
- Others see “fast” as a distinct, later step enabled by a clean, stable API that lets you swap implementations without changing behavior.
Correctness, performance, and architecture
- Many stress correctness first: a fast program that produces wrong results is useless.
- Some claim most performance problems are local (queries, functions) and fixable without re‑architecture.
- Others insist modern performance is largely architectural; if you don’t design for efficiency early, later “optimization” becomes a rewrite.
MVP, iteration, and “good enough”
- Strong support for “launch fast, iterate fast”: first version discovers the real problem; later passes refine and optimize.
- Critics note “prototype” or “temporary” code is rarely thrown away; kludges become permanent due to business pressure and prioritization.
- Several emphasize that software serves business needs; if something is “good enough” for customers and revenue, deeper rewrites are hard to justify.
Electron and resource usage
- Electron is used as a central case study:
- Pro‑Electron side: huge dev-pool, cross‑platform parity, and speed of development often outweigh RAM/CPU costs; companies optimize for velocity and viability.
- Anti‑Electron side: wasteful, pushes hardware/energy costs onto users, especially harmful for always‑running apps (chat, music).
- Some argue users mostly lack better options or understanding, not that they don’t care.
Process, refactoring, and risk
- Several advocate explicit cycles: prototype, then “do it right,” then “do it better,” sometimes with a deliberate “throw away the first draft” rule.
- Others warn that without time, authority, and culture to refactor, steps 2 and 3 never happen.
- Concepts like reversible vs irreversible decisions and “last responsible moment” are mentioned as tools to decide when to invest in “right” vs “just ship it.”