Implementation strategy

Skill 05: Implementation Strategy & Execution

Purpose: Actually build the thing well, in an order that stays working, stays understandable, and stays verifiable at every step. Use when: You have a plan and are ready to build. Don't use when: You don't yet have clear requirements (requirements-and-success-criteria) or a plan (planning-and-decomposition). Building without them produces fast garbage.

---

Why this matters

Execution is where good plans go to die. The common failure is not typing speed, it is building in a way that becomes an unverifiable, tangled pile: fifteen things changed at once, nothing runnable until the end, and no idea which change broke what. This skill is about the discipline of building so that quality is preserved as you go, not bolted on afterward.

The central habit: keep the work in a runnable, verified state as often as possible, and change one thing at a time.

The core principle

Make it work, then make it right, then make it fast: in that order, and never skip straight to "fast." Get a correct, simple version running end-to-end first. Clean it up second. Optimize only what measurement proves is slow, third. Most premature optimization and premature abstraction is complexity you'll pay to maintain forever, bought before you knew you needed it.

---

The execution loop

Repeat for each task in your plan:

1. Pick the next single task from the plan (top of the list).
2. Know your check first: before writing anything, know how you'll verify this task ("done when …").
3. Build the smallest thing that could satisfy it. Not the general version. Not the future-proof version. The version that makes this check pass.
4. Run it. Verify against the check. Not "it looks right": actually run it and observe the result.
5. If it works: commit / save a known-good state, cross the task off, go to 1.
6. If it doesn't: fix it now, while the change is small and fresh (see systematic-debugging). Don't pile the next change on top of a broken one.

Never let the number of unverified changes grow large. A working state you can return to is your safety net.

Build order: the "make it work" sequence

1. Walking skeleton first: the thinnest end-to-end path (from Skills 01/03). Prove the whole thing connects.
2. Happy path: the main case working correctly on real input.
3. Edge cases and errors: empty, missing, malformed, too-big, unauthorized. Handle each deliberately (see robustness-and-failure-modes).
4. Cleanup: names, structure, duplication, comments. Make it readable now that it works.
5. Optimization: only if a real measurement shows it's too slow, and only the measured hot spot.

---

Execution disciplines (the habits that preserve quality)

Reuse before you build

Before writing new code, check what already exists: in this project, in the standard library, in dependencies you already have. Re-implementing something that's a few files over (or one stdlib call away) is the most common form of self-inflicted complexity. Look first, write second.

One change at a time

Change one thing, verify, then change the next. When you batch ten changes and something breaks, you've lost the ability to know which change did it. Small verified steps are faster than big unverifiable ones because debugging a small diff is trivial.

Match the surrounding style

New work should read like it belongs. Follow the existing conventions, naming, and structure of whatever you're working in. Consistency is a feature; a "better" style that clashes is a cost to every future reader.

Simplest thing that works

Don't add an abstraction for one use. Don't add config for a value that never changes. Don't build an interface with one implementation. You can always generalize later, when a second real case appears. Speculative generality is a debt you pay before you borrow.

Leave a check behind

For any non-trivial logic (a branch, a loop, a parser, anything touching money/security/data), leave the smallest runnable check that fails if the logic breaks: a tiny self-test or an assertion. This is how you and everyone after you know it still works. Trivial one-liners don't need one.

Keep it runnable

Prefer a sequence of states where the thing always runs, even if it does less. "Always green" beats "big-bang integration at the end." If you must break it temporarily, keep that window as short as possible.

---

Decision aid: how much structure does this need?

Signal	Lean simpler	Invest more
Lifespan	Throwaway / one-off	Long-lived, others depend on it
Readers	Just you, now	A team, or future-you in 6 months
Change rate	Rarely touched	Frequently extended
Blast radius	Isolated	Shared, central, hard to change
Certainty	You know the requirements	Requirements still moving

When in doubt, start simpler. It is far cheaper to add structure to simple code that works than to remove structure from a complex thing that doesn't.

---

Worked example

Task: Add "export report to JSON" to the cost CLI.

Weak execution: Simultaneously add a plugin system for "export formats," a config file for output options, an abstract Exporter base class, and JSON/CSV/XML exporters, none tested, then try to run it. It doesn't work and you can't tell why.

Disciplined execution:

1. Check first: "Given the sample data, --json prints valid JSON that parses back to the same totals."
2. Smallest thing: one function that takes the already-computed totals and prints json.dumps(totals). Wire --json to call it.
3. Run it, verify: pipe output to a JSON parser; confirm totals round-trip. ✅
4. Save known-good state. Cross it off.
5. Only if a second format is actually requested later do you introduce an abstraction, and by then you'll know its real shape.

One tested function beats an untested framework. If XML is never requested, you never paid for the plugin system.

---

Common failure modes

Failure	Fix
Big-bang build, nothing runs till the end	Walking skeleton first, integrate continuously.
Ten changes at once	One change, verify, repeat.
Premature abstraction / optimization	Make it work simply first; generalize/optimize on evidence.
Reinventing existing helpers	Search the codebase and stdlib before writing.
"Looks right," never actually run	Execute and observe every task's check.
Clashing with existing style	Match surrounding conventions.
No test/assert left behind	Leave one runnable check on non-trivial logic.

Red flags: stop and correct

• Nothing has actually run in the last several changes.
• You can't say which recent change would have broken the current failure.
• You're building a general/configurable system for a single concrete need.
• You're optimizing something you never measured.
• You wrote a chunk of logic with no way to tell if it's correct.

Definition of done for this skill

• Built in small, individually-verified steps, each leaving a runnable state.
• Walking skeleton → happy path → edges → cleanup → (measured) optimization.
• Reused existing/stdlib solutions instead of re-implementing.
• No speculative abstractions or unmeasured optimizations.
• Non-trivial logic has a check left behind.

See also

• planning-and-decomposition, supplies the ordered tasks.
• systematic-debugging, for when a step fails.
• self-verification, verifying the finished result.
• maintainability-and-extensibility, the "make it right" step in depth.