Iterative Development

Implementation order, dependency-first and value-first, architecture that emerges from requirements, and the complexity ledger every new component must answer.

Change → run → observe → fix, in loops small enough that each one teaches something. A system is grown from one that already works; scale is added after a working system and a measured bottleneck, not before either exists.

Q · You have a plan for the whole store and it will take weeks before anything runs end to end. How do you turn that plan into loops that each produce evidence, and when — precisely — does scaling belong in one of them?

Implementation Order

▶ lab

Product model → display products → cart → checkout without payment → order persistence → payment → failure handling → admin: one defensible sequence for the store, with the reason for each step. Not the only sequence — and the device says so.

Q · The store is decomposed into pieces and you can build any of them. Which do you build first, in what order, and how would you defend the order to someone who would have chosen differently?

Dependency First

If B requires A, build or understand A first. Obvious when said, skipped constantly in practice: checkout built before the cart exists, payment integrated before anyone knows what an order is, a feature started on top of a concept nobody has understood.

Q · You are about to build something and part of it depends on something else that does not exist or that you do not understand. How do you find the dependency before it finds you, and what do you do about it?

Value First

When the dependencies permit, build the thing a user could actually use. A store that shows products and takes orders without payment is usable in a way that a perfect cart on top of nothing is not. Contested — against building the riskiest thing first — and this lesson says how.

Q · Several pieces are buildable now and none depends on the others. Which one do you build, and how do you choose between the one a user could use today and the one that would tell you whether the project is feasible?

Architecture From Requirements

▶ lab

Need persistence → a database. A browser interface → a frontend. Logic the client must not control → a backend. Payment → an external provider. Result: Browser → Backend → Database, plus the provider. Every box has a requirement that put it there, and no box is there without one.

Q · You have the requirements for the store and a blank page where the architecture goes. How do you derive the boxes from the requirements — and how do you tell a box that a requirement put there from one that a habit did?

Add Complexity Only When Required

▶ lab

Single server and database. Repeated expensive reads → maybe a cache. Long-running work in the request → maybe a queue and a worker. Each "maybe" waits for the symptom it treats; complexity should have a reason, and the reason should be something you observed.

Q · The store runs on one server and one database, and you can already see the components it will need eventually. When does "eventually" arrive for each one, and what has to be true before you add it?

The Complexity Ledger

▶ lab

Every new component answers three questions in writing: what problem does it solve, what complexity does it introduce, what happens if it fails. A component that cannot answer all three is not yet justified; one that can is accountable for as long as it lives.

Q · Someone proposes adding a component to the store — a cache, a queue, a search engine, a second service. What must be written down before it goes in, and what does that record let you do later that nothing else does?