Chapter 1 — The Hats You Will Wear

“Adding manpower to a late software project makes it later.” — Fred Brooks, The Mythical Man-Month (1975)

“For which of you, desiring to build a tower, does not first sit down and count the cost, whether he has enough to complete it?” — Luke 14:28 (ESV)

Why This Matters

Brooks wrote that line about teams. Read it as a solo engineer and it turns into something colder: you cannot add anyone. There is no second developer to throw at Week 14. There is no tester who will find the bug you cannot see, no technical writer who will clean up the README the night before, no release engineer who already knows how to get the thing onto a server. There is you, sixteen weeks, and roughly 240 hours.

That constraint is the entire pedagogy of this course. In a normal software organization, the work of building a system is distributed — a product owner decides what it is for, an analyst writes down what it must do, an architect picks the pieces, a project manager tracks the budget, developers build, testers break, a writer documents, a release engineer ships. Each of those people is wearing a hat. In a capstone, one head wears all seven. You do not get to be good at only the fun one.

This week you are in the Inception phase of the software development life cycle, and the hat you are wearing is the project manager’s — with a bit of the release engineer’s, because you are also standing up the shop. Notice what you are not doing this week: you are not choosing an idea. That is Week 2. It feels backwards, and students hate it every single year. Do it anyway. A professional walks into a new job on Monday and the product spec is not on the desk — the workspace is. You set up the repository, the board, and the log before the work arrives, because once the work arrives you will never again have a quiet week to set them up. Every hour you spend on infrastructure in Week 1 is an hour you are not spending on it in Week 13, when you will not have it.

The AI thread starts here too, and it runs from both sides for all sixteen weeks. As a tool, an assistant will happily take this course plan and hand you a personal week-by-week calendar in ninety seconds — a genuinely useful thing, and a thing you must then correct, because it does not know about your other three classes, your job, or Thanksgiving. As a governance problem, you are about to sign your name to work you did not type. That is not automatically wrong; it is automatically your responsibility. So this week you decide, in writing, before you need it, which tools you will use, for what, and how you will disclose it. That decision goes in docs/ai-usage.md and it is part of your grade in Week 16. The spine rule of this book, which you will hear until you are sick of it: the human stays in the loop where the judgment lives. AI accelerates; you decide, you verify, and you are accountable.

And under all of it sits this week’s question, which is older than software: what does it cost to finish what you start? Not “can you start” — anybody can start. The tower in Luke 14 has a foundation. Somebody laid it. Somebody meant it. The tragedy in that passage is not laziness; it is a builder who began in earnest and had not counted. You are about to lay a foundation in public, on GitHub, with a date on every commit. Before you do, sit down.

1.1 — What a Capstone Actually Is, and the Four Ways Students Fail One

A capstone is not a large homework assignment. It differs in kind, not in size.

That last row is the one that reorganizes everything. The Week-16 test is not “does it impress me.” It is: can somebody who has never seen this project clone it, run it, understand the architecture, and pick up the next task? Hold that sentence — it is the hard test behind three-quarters of your grade — the 50 percent final plus the 25 percent of milestones that build it. And here is what goes wrong on the way to it. Across capstone courses the failures are boringly repetitive, and there are four of them.

Look at that fourth one carefully, because it is the one that surprises good programmers. A student can work three hundred honest hours and still hand in something that cannot be graded above a C, because the work left no trace. Industry is exactly the same and much less forgiving: the engineer who built the thing and the engineer who can show what they built and why are paid differently.

Coach’s Note — The most dangerous week of your capstone is Week 5. Weeks 1–4 have novelty carrying you. Week 8 has a review with your name on it. Week 5 has neither, and it is where the late start is actually born. Put a note in your calendar now that says “Coach said this week would be hard.” You will thank me.

1.2 — The Software Development Life Cycle, Honestly Mapped

The software development life cycle (SDLC) is just the name for the sequence of things that have to happen between “somebody has a problem” and “somebody else is running the software.” Every methodology in the field is an argument about the order and the batch size of those things, not about whether they exist.

The honest history, briefly, because you will be asked about it in an interview. Waterfall is the strictly sequential model, usually traced to Royce’s 1970 paper — and the irony worth knowing is that the paper presented the pure single-pass version as risky and argued for iteration; the industry took the diagram and skipped the argument. Spiral is Boehm’s risk-driven model: do the scariest thing first, in a small loop, before you commit budget. The Unified Process is where the phase names inception, elaboration, construction, transition come from — this course borrows those words on purpose. Agile is the 2001 manifesto and everything after it: short iterations, working software, change welcomed late.

None of them repeals the life cycle. Agile does not delete requirements; it writes them smaller and later. Waterfall does not delete iteration; it just batches it badly.

So what is this course? Staged, but iterative inside the stages — and honest about why. You front-load requirements and design for two reasons that both apply to you and would not apply to a ten-person team. First, you are being graded on documents that a team would produce anyway, and producing them after the code is a lie in the shape of a document. Second, you are one person: when you thrash, there is nobody to absorb it. A team can survive a mid-project pivot. A solo builder with a 240-hour budget usually cannot.

Here is the whole course in one table. Print it. Tape it somewhere.

Two things to notice about it. First, construction is three weeks out of sixteen. If your mental model of a capstone is “sixteen weeks of coding,” it is wrong, and the correction is going to be uncomfortable. Second, every row consumes the row above it. Week 11’s test plan is written against Week 3’s requirement identifiers. Week 14’s handoff guide is assembled from Week 6’s architecture and Week 5’s decision records. Skip a row and you do not save a week — you buy a debt that comes due with interest in a week that has no slack.

Coach’s Note — “Waterfall vs. agile” is a bad interview question and an even worse religion. The good question is: how big is the batch between deciding and learning whether you were right? Small batches in unfamiliar territory, bigger batches where you have done it before. That is the whole art, and it is why Week 9’s walking skeleton exists.

1.3 — The Seven Hats

Naming the hat is a real technique, not a metaphor for the syllabus. It works because each hat asks a different question, and you cannot ask two questions at the same time well.

The eighth hat, the release engineer (“does it run on a machine that isn’t mine?”), is folded into the developer and writer weeks here; it shows up hard in Weeks 9 and 14. Three things about wearing all of them.

One: you will default to the developer hat. It is the most fun, the feedback is fastest, and it is the one you have practiced for three years. Every solo builder drifts toward it. The specific way this ruins a capstone is that you start writing code in Week 4 “just to try something,” and the code becomes the design by accident. Now the architecture is whatever you happened to type on a Tuesday, and the decision record you write in Week 5 is a rationalization.

Two: the hats disagree, and that is the point. A healthy internal argument in Week 5 sounds like this:

Developer: I can have the auth working tonight, I’ve done this before. Architect: We haven’t decided whether we even need accounts. Product owner: The one user I talked to never mentioned logging in. Project manager: Auth is nine hours we have not budgeted and it retires no risk.

In a company that is a meeting. Alone, it is a paragraph you have to actually write down, or the developer wins by default — because the developer is the only one holding a keyboard.

Three: the tester hat requires deliberate hostility to your own work. A team gets this for free — the tester did not write the code and has no ego in it. You have to manufacture it, and the mechanism we use is structural rather than emotional: in Week 11 you write tests against requirement identifiers from Week 3, not against the implementation in front of you. You test what you promised, not what you built. If those two differ, you have found either a bug or a broken promise, and both are worth knowing.

Coach’s Note — When you sit down for a work session, say out loud which hat you are wearing, and put it in the hours log. Two things happen. You stop half-coding during design time, and by Week 8 your log tells you the truth about which hat you avoid. Everybody avoids one. Mine was the writer’s for about a decade.

1.4 — The 240-Hour Budget: Where the Hours Actually Go

Sixteen weeks at about fifteen hours a week is 240 hours. That is the budget. It is not a target and it is not a promise; it is a ceiling you are going to spend against, and the first job of a project manager is to know where the money went.

By phase, the course allocates it like this:

Now cut it a second way — by activity rather than by week, because activities bleed across weeks and this is the cut that shocks people.

Be clear about what that second table is: it is this course’s budget, a teaching estimate for a project shaped like this one. It is not a measurement of the software industry and I am not going to dress it up as one. The number that matters is not mine — it is the one your own hours log will produce by Week 8, and yours will differ. What is durable is the shape: coding is roughly a third of the work, and the majority of your hours go to deciding, verifying, and explaining. Students who believe otherwise budget as if coding were 90% of the job, and then discover in Week 13 that documentation is not a rounding error.

Three pieces of budget arithmetic that will save you:

• Fifteen hours is not fifteen slots. Work that requires holding a system in your head has a warm-up cost. Fifteen hours as five three-hour blocks is roughly twice as productive as fifteen hours as fifteen one-hour interruptions. Schedule blocks.
• Budget slack, or life will take it without asking. Plan around 13 hours of real work per week and hold two in reserve. You will use them. Everybody uses them.
• The two weeks that are already broken. Look at your semester calendar right now and find the two weeks where fifteen hours is not going to happen — another course’s midterm, a holiday, a work trip. Those hours have to move forward, not backward. Decide now which earlier week absorbs them.

Coach’s Note — Every builder who has ever made a schedule has been optimistic, and every one has been wrong in the same direction. When you write your first estimate in Week 7, multiply it by 1.5 before you show anyone. Then in Week 12, compute your actual factor from your own log. Mine, measured honestly over years, is a little over two. Knowing your number is a professional skill; pretending it is 1.0 is a student habit.

1.5 — Your Engineering System: The Repository, the Board, and the Log

Three artifacts, standing up this week, before there is an idea. Together they are your engineering system: the machinery that turns effort into evidence.

The repository

One Git repository, on GitHub, created this week and never re-created. (GitHub has offered free private repositories to individual accounts for years and its built-in Projects boards are available on free accounts as of this writing — but tiers change, so confirm current terms before you depend on one. If your institution provides an account, prefer it.) You may keep it private now and open it at the end, or share it with your instructor; what you may not do is start over in Week 6 because the history embarrasses you. The history is evidence. A commit graph with work on forty distinct days is an argument no essay can make.

This is the canonical layout for this course. Create it now, with placeholder files:

capstone/
├── README.md                 # what this is, who owns it, how to run it, status
├── LICENSE                   # chosen in Week 5, or a dated "deferred" note
├── CHANGELOG.md              # change table in Week 8; release sections from Week 12
├── .gitignore
├── docs/
│   ├── charter.md            # THIS WEEK
│   ├── hours-log.csv         # THIS WEEK, and every week after
│   ├── ai-usage.md           # THIS WEEK, and every week after
│   ├── scoping-decision.md   # Week 2
│   ├── requirements.md       # Weeks 3–4
│   ├── definition-of-done.md # Week 4
│   ├── traceability.csv      # Weeks 4 and 11
│   ├── architecture.md       # Week 6
│   ├── plan.md               # Week 7
│   ├── risk-register.md      # Week 7
│   ├── test-plan.md          # Week 11
│   ├── test-results.md       # Week 11, re-run and re-recorded Week 16
│   ├── defect-log.md         # Week 11
│   ├── runbook.md            # Week 13
│   ├── clean-machine-test.md # Week 13
│   ├── handoff.md            # Week 14
│   ├── retrospective.md      # Week 16
│   ├── adr/                  # Week 5 onward — one file per decision
│   └── change-requests/      # Week 8 onward — one file per change request
├── src/                      # Week 9 onward
├── tests/                    # Week 9 onward
└── .github/workflows/        # Week 9 — continuous integration

Every line on the Week-16 rubric has a slot in that tree. Not every slot is its own rubric line — the charter, the scoping decision, the definition of done, the plan, and the risk register are working documents that feed a graded line rather than earning points under their own name — but nothing you are graded on in Week 16 is missing a home here. Audit your repository against this tree in Week 16 and you will have checked every graded artifact. You are not making a folder structure; you are making a shelf with a labelled slot for each thing you will be graded on. Empty slots are visible, which is the point. Branching, for one person: work on a branch named for the requirement you are satisfying (fr-014-expiry-warning), merge to main when the tests pass. You do not need to review your own pull request, and I am not going to pretend you do. You do want the branch, because it makes the change log write itself in Week 12 and it makes continuous integration mean something in Week 9. Commit messages get the requirement identifier in front — FR-014: warn when an item expires within 3 days — so that in Week 11 you can answer “which commits implemented FR-014?” with one command.

The board

A board is a queue with a limit. Five columns — Backlog, This Week, In Progress, Blocked, Done — and a work-in-progress limit of two in the In Progress column. That limit is the entire value of the board; without it you have a list, and a list of forty things is a mood, not a plan.

GitHub Projects is the default recommendation because it lives next to the repository and can link cards to issues and commits. If you would genuinely rather use something else, use it — but a board in a tool you will abandon by Week 6 is worse than no board.

Cards are verifiable work items, not nouns. This distinction is small and it decides whether the board helps you:

Bad card

Build the backend

Good card

FR-014 — Warn on items expiring within 3 days
Estimate: 3h   Hat: developer   Branch: fr-014-expiry-warning
Done when: the acceptance criteria for FR-014 pass and CI is green on main.

The bad card cannot be finished, cannot be estimated, and cannot be moved to Done without an argument with yourself. The good one has an owner, a size, a home, and a stopping condition. In Week 3 the FR-014 will come from your requirements document; this week your cards are about the engineering system itself, and they follow the same rules.

The log

docs/hours-log.csv. It goes in the repository, in version control, next to everything else. Not a spreadsheet in your downloads folder. It gets its own section, because it is the artifact students take least seriously and it is the one that will change how you work.

1.6 — How to Track Time So the Number Means Something

You cannot learn to estimate without measuring. That is the whole argument. Professionals estimate; estimation is a calibrated skill, and calibration requires a feedback loop between what you predicted and what happened. Sixteen weeks is exactly long enough to build that loop if you start in Week 1 and useless if you start in Week 9. Use the provided template, code/hours-log.csv. The columns:

date,start,end,hours,phase,hat,task,estimate_hours,blocked_hours,notes

The rules that make the number mean something:

1. Log at the end of the session, not the end of the week. A retro-filled log is fiction with a CSV extension. It is also, in a course that grades honesty, a small lie you will have to sign.
2. Round to the quarter hour. Precision beyond that is theater.
3. Write the estimate before you start. One number, in the estimate_hours column, guessed cold. That column is worthless the moment you fill it in afterward.
4. Log blocked time separately. The forty minutes you spent fighting an SDK that would not install is real, it is not “development,” and it is the number that predicts your risk register in Week 7.
5. Log rework. When you rebuild something you already built, say so in the notes. Rework is the highest-value signal in the whole file, because it points at a decision made too early.
6. Log the hours that produced nothing. Especially those.

Here is a week of a bad log next to the same week logged well.

Bad

date,start,end,hours,phase,hat,task,estimate_hours,blocked_hours,notes
2026-09-07,,,5,,,worked on project,,,
2026-09-10,,,4,,,project stuff,,,
2026-09-12,,,6,,,coding,,,

Good

date,start,end,hours,phase,hat,task,estimate_hours,blocked_hours,notes
2026-09-07,19:00,21:15,2.25,inception,project-manager,create repo + scaffold docs/ tree,1.5,0,underestimated .gitignore research
2026-09-08,20:00,21:00,1.00,inception,project-manager,board columns + WIP limit + 6 cards,1.0,0,
2026-09-10,17:30,20:30,3.00,inception,project-manager,draft charter: purpose + constraints,2.0,0.5,blocked 30m on institution's GitHub SSO
2026-09-11,09:00,10:30,1.50,inception,release-engineer,verify clean-clone of repo in a codespace,1.0,0,worked first try
2026-09-12,13:00,16:00,3.00,inception,project-manager,charter non-goals + risks; rewrote purpose,2.0,0,rework: first purpose statement was unverifiable

Both logs claim about fifteen hours. Only one of them can answer a question. From the good log I can already tell you: this student underestimates by about 40%, loses time to institutional tooling, and rewrote their purpose statement once — which is a good sign, because it means they noticed it was bad. The bad log tells me a student was in the building.

The provided script code/hours_report.py prints hours by week, by phase, by hat, your cumulative total against the 240-hour budget, and your running estimate-to-actual ratio. Copy it into your repository (a tools/ directory is fine) and run it every Friday — four seconds, and it is the closest thing this course has to a scale.

python3 tools/hours_report.py docs/hours-log.csv

Coach’s Note — “A false balance is an abomination to the LORD, but a just weight is his delight.” (Proverbs 11:1, ESV). That verse is about commerce, and it lands squarely on an hours log. Nobody audits this file. That is exactly why it measures you.

1.7 — The Grading Contract: 50 / 25 / 15 / 10, and Why the Quizzes Exist

Say it once, plainly, and never wonder about it again.

Now the part students misread every year. The fourteen weekly milestones are graded twice. There is a line in the gradebook called “Milestone 6” — the fourteen of them together are 25% of your grade — and then everything Milestone 6 produced is graded a second time inside the 50% final.

Read that as double jeopardy and you have misread it. Here is the actual arithmetic: the milestones are the final deliverable, produced one week at a time. The Week-16 rubric awards points for exactly the artifacts the milestones produce. Skipping Milestone 6 costs you about 1.8 points of the course grade immediately, and then it costs you the same rubric points again, deferred to a week when there is no time left to earn them, and it costs you every downstream week that needed Milestone 6 as an input. The milestones are not assignments stacked next to the final. They are the final, disassembled into fourteen pieces you can actually carry — and you are paid for carrying each piece.

So what stops you from finding this out in Week 15? The quizzes. Sixteen of them, one a week, auto-graded, plus the Design Review Checkpoint in Week 8 — fifteen percent of the grade between them. They exist for two reasons, and the second is the real one. The first is ordinary: they check that the vocabulary of the life cycle is actually in your hands — that you can say what a non-functional requirement is, what an ADR records, what a walking skeleton proves. The second is that they are the early-warning system. A quiz you cannot pass is a week whose reading you skipped, and a week whose reading you skipped is a milestone you probably did not ship. Fifteen percent is small enough that no single quiz can hurt you and large enough that a pattern will. When you find yourself guessing on Week 6’s quiz, that is not a quiz problem. That is the late start, ringing a bell.

The full rubric, the pace table, and the submission checklist live in Appendix C. Read it this week. Read it again in Week 8. You are allowed to know exactly how you are graded; there are no surprises in this course, only deadlines.

1.8 — AI in This Course: The Tool, the Log, and the Line You Do Not Cross

You are going to use AI on this project. Pretending otherwise would make this book useless in about eighteen months. What this course insists on is that you use it like an engineer and not like a defendant.

Three zones. Learn them; they are the shape of most real corporate policies you will meet:

The Red line has a single, portable test, and I want you to be able to state it in an interview: you may not delegate a judgment you cannot defend. Not “you may not use AI.” Not “you must type every character.” You must be able to stand behind every decision in your repository, in your own words, under questions, in Week 16. If a model chose your database and you cannot say why that database and not the other two, the decision is not yours, the ADR is a forgery, and the design review in Week 8 will find it in about ninety seconds. It always does.

The disclosure log

docs/ai-usage.md starts this week, using code/ai-usage-template.md. It has a policy header — which tools you have decided to use, for what — and then one row per Amber-zone use, all semester. It is a required artifact in the Week-16 submission.

A bad entry

Week 3 — used ChatGPT for requirements.

A good entry

| 2026-09-22 | Assistant (note the product and model version you actually used)
| Asked: "Interview me about a household food-tracking app and list functional requirements."
| Kept: 6 of 19 proposed requirements, as raw material only.
| Changed: rewrote all 6 into FR-form with actor/condition; deleted 13 as out of scope
|          (it invented multi-household sharing and a mobile app I never mentioned).
| Verified: checked each against my Week-2 scoping decision; confirmed FR-004's
|          "3 days" threshold with my actual user rather than accepting the default.

The good entry takes ninety seconds to write and it is evidence of judgment. The bad one is evidence of nothing, which — in a course where three-quarters of your grade — the 50% final plus the 25% of milestones that build it — is “can you show your work” — is worse than not having used the tool at all.

Where it will fail you

• It will over-scope you. Ask an assistant whether your idea is feasible in 240 hours and it will usually say yes and then suggest three more features. It is trained to be agreeable. In Week 2 you will learn to prompt it as a skeptic instead.
• It will write “the system shall be user-friendly.” Generated requirements are consistently vague, unverifiable, and inflated. Week 3 is largely about repairing this.
• It will invent things that do not exist — library names, function signatures, configuration keys, license terms. The dangerous ones are plausible. Never take a licensing or cost claim from a model; read the actual license text at spdx.org/licenses or the vendor’s own page.
• Its schedule is a draft, not a commitment. In this week’s reps you will hand an assistant the sixteen-week map and ask for a personal calendar. Do it — it is a genuinely good use. Then find the three things it got wrong, because it does not know your life. What comes back is a proposal from someone who has never met you.

The other side of the thread — whether your project should contain an AI feature, and how you specify something whose output is probabilistic — is Week 2 and Week 3’s problem. Today you are only deciding how you will work, in writing, before the pressure arrives. Policies written under deadline are not policies. They are excuses with timestamps.

Coach’s Note — Write your AI policy this week while you still feel principled about it. In Week 12, at 1 a.m., with an integration failing, you will meet the version of yourself who wants to paste the whole repo into a chat window and accept whatever comes out. That person does not need a lecture. That person needs a decision that was already made.

1.9 — Interactive Lab: The SDLC Hat Map

Below this chapter on the website is the SDLC Hat Map widget. Use it now — before you do the reps, and again in Week 8. It is the sixteen-week timeline made clickable: click any week and it opens up the SDLC phase that week belongs to, the hat you wear, the milestone artifact due, the inputs it consumes from earlier weeks, and the concrete failure that follows from skipping it. A toggle overlays the cumulative hour budget so you can watch the 240 hours drain.

Three passes; do all three.

1. Left to right. Click Weeks 1 through 16 in order and read only the “inputs consumed” line. You are looking for the chains — the fact that Week 11’s test plan eats Week 3’s requirement identifiers, and Week 14’s handoff eats Weeks 5, 6, and 13. Nothing here is standalone.
2. Find your own failure. Click through and find the week you would most likely have skipped if nobody made you do it. Everyone has one; be honest about yours. Read the failure text for that week out loud. That is the sentence you are buying if you skip it.
3. Turn on the hour overlay. Find the week where the cumulative budget crosses 50%. Look at what is — and is not — built by then. Most students are startled that half the budget is gone before the core increment is done. That is not a flaw in the plan; that is what building software actually costs, and seeing it now is cheaper than discovering it in Week 12.

What the lab teaches: that a life cycle is a dependency graph, not a checklist, and that a schedule is a budget you spend rather than a wish you make.

1.10 — What Does It Cost to Finish What You Start?

“For which of you, desiring to build a tower, does not first sit down and count the cost, whether he has enough to complete it? Otherwise, when he has laid a foundation and is not able to finish, all who see it begin to mock him, saying, ‘This man began to build and was not able to finish.’” — Luke 14:28–30 (ESV)

First, say honestly what this passage is doing, because it is not a project-management proverb and treating it as one is the kind of shallow use of Scripture this book refuses.

Jesus is speaking to a large crowd that is following him, and the paragraph is severe. He tells them that following him will cost them their families’ claims on them, their comfort, their lives — and then he gives two small pictures, the builder and a king weighing whether to go to war, and closes by saying that anyone who does not renounce everything he has cannot be his disciple. The point is not “plan carefully so your projects succeed.” The point is that discipleship is not a casual affiliation, and that the person who signs up without understanding the price will be the one who quits publicly. The comfort in the passage is not in our accounting. It is that the cost we cannot pay was paid by Christ, and the call still stands.

But notice why the picture works as a picture. Jesus is appealing to something his hearers already knew about work — that a half-built tower is a public, permanent, embarrassing thing, and that a wise builder sits down first. That is real wisdom about human labor, offered by one who assumes you already recognize it. So we can take the wisdom seriously without pretending the parable is about our capstone. Here is what it says about your work.

Counting the cost is an act of humility, not pessimism. It requires knowing your own limits, which is the hardest kind of knowledge, and the kind our culture most actively discourages. The student who refuses to estimate is not being brave. They are avoiding a number that might tell them something true about themselves. Every hour in your log is a small confession: this is how fast I actually am. That is uncomfortable and it is the beginning of competence.

The shame in the passage is public and specific. Not “he failed” — “this man began to build and was not able to finish.” The mockery is aimed at the gap between the announcement and the result. It is the LinkedIn post about the ambitious project next to a repository whose last commit is four months old and whose README says “TODO: add setup instructions.” Your capstone will be public. That is deliberate. Working under a public record is a discipline, and it is the same discipline you will work under for the rest of your career.

And sometimes counting the cost yields “no.” This is the part students skip. If sitting down and doing the arithmetic tells you that this idea does not fit in 240 hours, the faithful response is not to start anyway and hope. It is to build a smaller tower and finish it. That is precisely what Week 2 asks of you when it makes you kill two of your three candidate ideas on purpose. Killing an idea you love, early, with your eyes open, is not failure. It is the whole skill the passage is commending. An unfinished cathedral glorifies nobody; a finished chapel shelters somebody.

There is one more turn, and it is Lutheran to the bone. Luther taught that ordinary work is a station of service — that God feeds people through farmers and bakers, and that our vocations are the ordinary means by which he cares for our neighbors. Which means the question “what does it cost to finish?” is not really about your grade. Something you finish can serve someone. Something you abandon serves no one, no matter how clever the abandoned parts were. The reason Week 14 makes you write a handoff guide for an engineer you will never meet is not that handoff guides are on the rubric. It is that finishing is how work becomes a gift instead of a monument.

So sit down. Count. Then build the thing you can actually finish, and finish it.

1.11 — Common Pitfalls

Pitfall: Waiting for the idea before standing up the engineering system. Example: “I’ll make the repo once I know what I’m building.” Week 4 arrives; there is no repo, no log, and no evidence any work happened in Weeks 1–3. Fix: Build the shop first. The repository, the board, and the log are stack-agnostic and idea-agnostic — that is exactly why they belong in Week 1, the only quiet week you get.

Pitfall: Retro-filling the hours log on Sunday night. Example: Five rows appear at 11:40 p.m., each a suspiciously round number, none with a start time. Fix: Log at the end of every session, before you close the laptop. Sixty seconds. If a week is genuinely reconstructed, mark it reconstructed in the notes — an honest gap beats an invented record, and your grader can tell the difference.

Pitfall: Treating a milestone as cheap because it is “only” about 1.8 points of the course grade. Example: Milestone 5 gets skipped in a busy week. In Week 6 the technical specification has no decision records to reference; in Week 8 the design review has nothing to review. Fix: Reread §1.7. You lose the milestone points and the milestones are the 50% final, delivered in pieces — so skipping one charges you twice, defers identical rubric points into a week that has no slack, and starves every week that depended on it.

Pitfall: A board made of nouns. Example: Cards reading “Backend,” “Frontend,” “Database.” Three months later all three are still In Progress. Fix: Every card is a verb with a stopping condition and an estimate: “FR-014 — warn on items expiring within 3 days; est 3h; done when FR-014’s acceptance criteria pass and CI is green.” If you cannot say when it is done, it is not a card, it is an anxiety.

Pitfall: A charter with no non-goals. Example: A purpose statement listing everything the project might someday do, and nothing it will not. Fix: Write at least five explicit non-goals this week. They are the only part of a charter that can stop a bad decision in Week 10 — the only part you can point at when a new feature is tempting.

Pitfall: Letting the assistant make the decision and pasting its answer as your record. Example: An ADR whose “consequences” section is fluent, balanced, and describes tradeoffs the student cannot explain when asked. Fix: Use the tool for options and objections; write the decision in your own words, in the first person, naming what you gave up. Then log the use in docs/ai-usage.md. A decision you cannot defend out loud is not yours, and Week 8 exists to find out.

Pitfall: A single branch and forty commits named “update.” Example: git log is a wall of update, fix, wip, stuff. In Week 12 you cannot assemble a change log; in Week 11 you cannot tell which commits implemented which requirement. Fix: Branch per requirement, requirement identifier at the front of every commit subject, one logical change per commit. Costs nothing now; writes two graded artifacts for you later.

1.12 — Where Your Hours Went This Week

A realistic ledger for Week 1. Yours will differ; log what actually happens.

If you finish in six hours, you did the typing and skipped the thinking. The charter is not a form.

1.13 — Reps

The reps are in the exercises — not warm-ups next to the milestone, but the milestone itself, built piece by piece. Preview:

• Rep 1 — create the repository and scaffold the canonical docs/ tree in one commit.
• Rep 5 — rewrite four garbage log rows into rows that mean something, then wire your own with code/hours_report.py.
• Rep 9 — write your AI policy, then run one deliberate Amber-zone use and log it properly.
• Rep 10 — have an assistant turn the sixteen-week map into your personal calendar, then find the three things it got wrong.

Then take the on-page Check Your Reps quiz. It is an ungraded self-check you can retake as often as you like; the graded one is Week 1 Quiz in Canvas, which draws a fresh random set from a larger pool over the same material. Together the sixteen weekly quizzes and the Week-8 checkpoint are 15% of your grade — but more usefully, they are the bell that tells you whether you are on pace.

1.14 — This Week’s Milestone

Milestone 1 — Milestone 1: Project Charter & Engineering System. A repository with the canonical structure, a charter that counts the cost in writing, a live board, an honest hours log with real Week-1 rows, an AI-use policy, and a README.md that orients a stranger. Nothing in it requires you to know what you are building. That is the design. Ship the shop; the work arrives Monday.

1.15 — Coach’s Final Word

You have no idea yet, no code, no stack, and no design. By Friday you will have a repository a stranger could navigate, a board with a limit on it, a log that knows how many hours you really worked, and a written decision about how you will use the most powerful tool you have ever had access to.

That is not a slow start. That is a start with a foundation under it — which is the only kind that gets finished. Fifteen weeks from now somebody is going to clone your repository on a machine you have never touched and try to run your software. Everything we do between now and then is aimed at that moment; this week you are laying out the tools, in order, on the bench, so that when the real work comes you are not looking for them.

Sit down. Count the cost. Then build.

See you on Monday.

Up next: the exercises builds the engineering system rep by rep · Milestone 1 is this week’s milestone · then Chapter 2 — where you find an idea worth 240 hours and kill two that are not. Reference appendices: Appendix A (your workbench), Appendix B (the document kit), Appendix C (the grading contract), Appendix D (fifty sized ideas), Appendix E (glossary).