Exercise 10 — Capstone: Evolution, and the Portfolio

What you are producing

The capstone — about four hours — in two halves. The first changes the system; the second assembles everything behind you into something another person can read.

Evolution — a technical debt assessment · a legacy strategy · a buy-vs-build decision · a migration sequence

Closing — a competency gap analysis · a 12-month learning roadmap · the final portfolio

Two things here are meant to be uncomfortable

The debt assessment asks you to name work as badly done rather than deliberate — about colleagues you need. And the portfolio asks you to reconcile contradictions between what you wrote in Exercise 1 and what you know by Exercise 10. Both are the point.

Half one — evolution

1. Technical debt assessment. Six to eight items, each classified by quadrant with the response its classification implies. Reclassify at least one honestly — something on your list bought no acceleration and recorded no trade; name what it actually is. Apply the design payoff line to one specific decision, per area rather than per system. Then reorder by change frequency, because carrying cost follows how often code is touched rather than how bad it is.

2. Legacy strategy. Establish the migration’s observed rate, with the arithmetic shown, and say what that makes true about dependency lifetimes. The decisive question: does your initiative compete with the migration for capacity, or produce seams it needs? Do not propose a rewrite — the behaviour is not known.

3. Buy-vs-build decision. Four or five components, each with a call and a named reconsideration trigger someone could check without asking you. Price the switch for one purchased component and say which cost is largest.

4. Migration sequence. Ordered by dependency on scarce context, not architectural tidiness. User-visible value in stage one. The riskiest assumption tested in the earliest stage that can test it. And state explicitly what you are not asking for.

Half two — closing

Gap analysis

Score the objectives of Modules 1–9 honestly against your current ability. A score needs evidence, not an impression — “I can do this” means you have done it somewhere the feedback arrived.

Score separately against the six rising competencies, and separate what you can verify from what you can produce. That gap is how far your delegation can safely extend.

The diagnostic: are your low scores in things no guide could teach, or things you skipped? Those imply different plans.

Learning roadmap

Twelve months. Every item passes one test: does this change the class of decision I am qualified to make?

• Learn now: two or three items
• Defer: with the reason
• Deliberately skip: at least three, each with a reason you will write down
• Checkpoints at three, six and twelve months — observable, dated, and attached to a decision about what changes if missed

A roadmap of technologies is horizontal by construction. One with no exclusions is a wish list.

The portfolio

Every artifact from Exercises 1–10, assembled in the order a reader needs rather than the order you produced them, plus a two-page executive summary.

The summary must be comprehensible to someone who never read this guide: the business problem in the organisation’s own terms, what you recommend, what it costs and returns, the three largest risks, and what remains unproven. None of this guide’s vocabulary, no module references.

Reconcile the contradictions

The rubric item that separates a portfolio from a folder. Nine modules of work by someone who was learning contains inconsistencies. Three honest responses: fix it, supersede it with a record, or acknowledge it in a note. Hiding it is not among them.

Look first at: the stakeholder map from Exercise 1 against the influence map from Exercise 8 · the regression trigger in Exercise 2’s NFR budget against the noise floor in Exercise 6’s evaluation plan · whether Exercise 3’s reference architecture treated the monolith dependency as temporary, against this exercise’s rate arithmetic · Exercise 5’s blast-radius tiers against the two-process credit finding from Handbook Modules 9 and 10.

Rubric

1. Classified by quadrant, with responsesEach debt item carries the response its classification implies.

2. One item honestly reclassifiedSomething on the list is not debt. Say what it is instead.

3. The payoff line, applied specificallyTo one real decision, per area rather than per system.

4. Value before completionThe sequence delivers something user-visible before it finishes.

5. A named reconsideration triggerObservable and checkable by someone else.

6. No capacity that does not existThe plan does not assume engineers nobody can spare.

7. Real weaknesses, not diplomatic onesThe gap analysis scores on evidence.

8. Names what you will not learnAt least three, with reasoning.

9. One engagement, not ten exercisesAnd contradictions reconciled or acknowledged.

10. The summary stands aloneComprehensible to someone who never read the guide.

Self-check

• Does every debt item have a response, or only a label?
• Is at least one item reclassified, with the framing you would use out loud?
• Does your legacy strategy show the rate arithmetic rather than asserting a conclusion?
• Does it name structural work that serves both roadmaps?
• Can a stranger check every reconsideration trigger without asking you?
• List what you ask from the existing programme. Is it bounded and specific?
• If funding stopped after stage one, what would the company have?
• Does any score rest on an impression rather than work where feedback arrived?
• Does your roadmap name at least three deliberate skips?
• Did you find at least three contradictions between early and late artifacts? What did you do with each?
• Can a stranger read the executive summary and state your recommendation back to you?

Where this leaves you

Ten modules, four parts, and one architecture for a company with a legacy monolith, no spare capacity, and a previous failure nobody talks about.

What the guide could give you is the frameworks, the arithmetic habits, and a complete worked engagement. What it could not give you is the thing only production gives: confirmation that your judgement was right. Every decision in your portfolio is defensible and none has been tested, and knowing the difference between those two words is itself one of the more useful outcomes here.

Check your understanding

Return to the questions from the start of the module.

1. Name something called technical debt in a system you know. Was it a deliberate trade, or just mess?
2. A migration has been “nearly done” for a long time. What was the actual remaining work?
3. If someone asked for evidence that you can do architectural work, what would you show them — and is it different from ten modules ago?
4. Six months from now, what will tell you whether this was ten modules of reading or ten modules of learning?

---

→ That is the Workbook, and the portfolio is the guide’s real output. Everything in it is defensible; the next step is to find out what is correct.