How do you balance shipping fast for a deadline against building it right for maintainability?

Question

Accepted Answer

There is no absolute answer, and that is the point. **Speed vs. maintainability is contextual** — you match rigor to the **stakes** and the **expected lifespan** of the code. A throwaway prototype and a payments core deserve very different bars. The lead's job is to make that trade-off **deliberately**, not let it happen by accident.

## A framework for deciding

Ask three questions before cutting a corner:

- **How long will this live?** A one-week experiment can be scrappy; a core service you'll maintain for years cannot.
- **What's the blast radius if it breaks?** Higher stakes (money, data, security, hard-to-reverse changes) means a higher bar.
- **How hard is it to change later?** Cheap-to-replace code tolerates shortcuts; load-bearing interfaces and data models do not.

## Deliberate vs. accidental shortcuts

- A **deliberate** shortcut is named, scoped, and **tracked as debt** (a ticket, a `// TODO`, a note in the RFC). You know exactly what you traded and why.
- An **accidental** shortcut is silent quality erosion — no one decided it, no one tracks it, and it compounds.

Keep the **core clean** even under pressure: well-named boundaries, tested critical paths. Push the mess to the edges where it's cheap to rip out.

## Negotiate the triangle, don't silently cut quality

When a deadline is tight, the honest move is to renegotiate **scope or time** with stakeholders — not to quietly ship something brittle. "We can hit the date with feature A and B, but C slips a week" is a real conversation. Silently shipping fragile code spends the team's future velocity without anyone agreeing to it.

## Why it matters

Teams that always optimize for speed drown in debt; teams that always gold-plate miss markets. The lead's value is judgment — calibrating rigor to context and making the trade-off **visible and owned**, so today's shortcut is a choice the team can pay back, not a surprise it inherits.