Everything from

martinfowler.com

3 resources from martinfowler.com we point founders to, and the questions each answers.

📄 Article
✓ Link checked Free Intermediate

Why we picked it If Spolsky tells you not to rewrite from scratch, this gives you the alternative: replace the old thing piece by piece while it keeps running, so you never take a big-bang risk. Fowler's strangler fig metaphor (a new system grows around the old one until it can stand alone) is the practical middle path between suffering the MVP and blowing it all up. A good next read once you have decided some part genuinely needs replacing.

Strangler Fig Application

From martinfowler.com by Martin Fowler ~8 min read

  • You can modernize a system incrementally by building new features alongside the legacy code and gradually routing traffic away from the old path, instead of a risky all-at-once cutover.
  • Investment and returns arrive gradually and visibly, so you can stop, ship, or change course at any point rather than betting everything on one launch.
  • A facade or proxy in front of old and new lets you shift functionality over piece by piece while the product stays live for users.
Open martinfowler.com →
Answers When is the right moment to stop iterating on the MVP and rebuild it properly, and how do I avoid the second-system rewrite trap?
✍️ Essay
✓ Link checked Free Intermediate

Why we picked it This is the canonical explanation of what a reviewer actually means when they flag your inherited code as risky. Fowler frames messy code as debt you pay interest on: every future feature gets slower, which is the real cost you inherit from a rushed agency build. Read it to understand why a reviewer separates crufty-but-stable code (leave it) from cruft in code you touch often (fix it), so you can read a review report with judgment instead of panic.

Technical Debt

From martinfowler.com by Martin Fowler About a 10 minute read

  • Technical debt is not about ugly code, it is about the extra time every future change costs you.
  • A reviewer prioritizes cruft in frequently changed areas, and often leaves stable messy code alone.
  • The deliberate versus reckless, prudent versus inadvertent quadrant helps you judge how worried to actually be.
Open martinfowler.com →
Answers How do I evaluate the code quality of a build I inherited from an agency?
✍️ Essay
✓ Link checked Free Beginner

Why we picked it This is the canonical framing for exactly your question: not all messy code is the same. Fowler splits debt on two axes, whether you took it on deliberately or by accident, and whether the call was prudent or reckless. For a two-person team shipping fast, the useful cell is deliberate and prudent: you know you cut a corner, you thought about the payoff, and you plan to come back. That is a healthy place to be, and this piece gives you the language to tell it apart from the reckless kind that actually hurts.

Technical Debt Quadrant

From martinfowler.com by Martin Fowler About a 5 minute read

  • Debt taken on deliberately and prudently (a conscious shortcut with a payoff in mind) is fine, and often smart, when you are racing to ship.
  • The debt to fear is the reckless kind: messy code from not knowing better, or knowingly cutting corners you cannot afford. That is the interest that compounds.
  • Some debt is inadvertent and prudent, you only learn the right design after building it. That is unavoidable and not a failure, so do not beat yourselves up over it.
Open martinfowler.com →
Answers We ship fast but our codebase is turning into a mess. How much should a two-person startup care about tech debt?