Chapter 1 — Commit to a Project by Friday

“The bearing of a child takes nine months, no matter how many women are assigned.” — 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 parallelism, and it is the first thing you need to hear in an accelerated course. Some things do not compress. A requirement still has to be written down once, carefully, by somebody who understands it. A design decision still has to be argued and recorded. A stranger still has to be able to clone your repository and run your software, and no amount of urgency makes that easier. You have half the calendar of a normal capstone and you are producing the same professional package.

So the compression has to be bought somewhere real, and this book buys it in exactly one place: you do not get to shop for an idea. In the sixteen-week edition, Week 2 is a search — six sources, three candidates, interviews, a scorecard, two ideas killed. It is good pedagogy and it costs about a month of elapsed time. You do not have a month. Appendix B, the Fast-Start Catalog, hands you twelve pre-scoped briefs: a real problem, a named user, eight to ten drafted functional requirements with acceptance criteria, four to six drafted non-functional requirements with measurable targets, the genuinely hard part, a stack already sized to the budget, and a what-to-cut-first list. You adopt one and adapt it, or you bring your own project and use a brief as the template. Either way the blank page is gone by Wednesday and you are writing requirements on day eight instead of day thirty.

That trade has a consequence, and it is the skill this whole edition is built around: the accelerated engineer’s core competence is adapting, not authoring. Editing inherited material well is harder than it sounds and worth more in industry than starting from nothing, because starting from nothing is a luxury almost no professional gets. You will join a team with a codebase, a requirements document somebody else wrote, and a backlog you inherited, and your job on day one will be to work out which of those sentences still describe reality. That is exactly this course’s job in Weeks 1 and 2 — and it has a signature failure mode I will repeat until you are sick of it: a requirement you keep without repairing is a requirement that quietly describes somebody else’s project.

This week you wear two hats at once — the project manager’s and the product owner’s — because in eight weeks you cannot afford to wear them in sequence. You are in inception, and inception is one week long. By Friday you will have a repository with a place for everything, a board with a limit on it, an hours log that knows the truth, a written AI policy, a chosen and adapted project, and a scoping decision a stranger could check. The AI thread starts here too, from both sides. As a tool, an assistant is excellent at one specific job this week: pressure-testing a brief against your actual situation — “here is the brief, here is my week, argue that this is too big for me” — thirty minutes, and it will name four tasks you had not counted. What it must not do is invent an idea for you, because an idea you did not evaluate is an idea you cannot defend in Week 8. As a governance problem, you are about to sign your name to work you did not type, at a pace that will make cutting corners feel reasonable, so the policy goes into docs/ai-usage.md now, while you still feel principled about it. The spine rule, every week: the human stays in the loop where the judgment lives. AI accelerates; you decide, you verify, and you are accountable.

And underneath it sits this week’s question, older than software and sharper in a short term than a long one: what does it cost to finish what you start? Anybody can start. The tower in Luke 14 has a foundation under it — somebody laid it, somebody meant it. The tragedy is not laziness; it is a builder who began in earnest and had not counted. You are about to lay a foundation in public, with a date on every commit, and eight weeks to finish it. Before you do — sit down.

1.1 — Eight Weeks Changes One Thing: You Do Not Get to Shop for an Idea

A capstone differs from homework in kind, not size: nobody writes the specification for you, nobody knows the right answer in advance, and what is graded is whether the process and the artifacts hold up under a stranger’s hands. The Week-8 test is the same as the long edition’s Week-16 test — can somebody who has never seen this project clone it, run it, understand the architecture, and pick up the next task? What changes is the clock, and the clock changes which failures kill you.

Read the first two rows together, because in eight weeks they stop being separate failures. Deciding late and deciding big are the same mistake here, and they compound: every day spent admiring options is a day removed from construction, and the longer you shop the more attached you get to something too large. So you are not choosing between twelve projects for a week. You are shortlisting three by Tuesday, killing two by Wednesday, and adapting the survivor by Friday.

Now say the other half plainly, because students hear “pre-scoped brief” and think “reduced rigor.” Nothing professional is cut. You still produce a charter, a scoping decision, a requirements specification with measurable non-functional requirements, architecture decision records, a technical specification, a plan and a risk register, a tested increment, a defect log, an hours log, a README, a runbook, a handoff guide, a change log, and a tagged release. The eight-week package is the same package. What shrinks is the system, not the discipline.

Coach’s Note — The most dangerous week of this course is Week 4. Weeks 1–3 have novelty carrying you and a review with your name on it at the end; Week 5 has construction, which is fun. Week 4 is a review, an audit, and a checkpoint, and it is where students who are quietly behind find out in public. Put a note in your calendar now that says “Coach said this week tells the truth.”

1.2 — The Compressed Life Cycle, and What Is Not Cut

The software development life cycle names the sequence of things that must happen between “somebody has a problem” and “somebody else is running the software.” Every methodology argues about the order and the batch size of those things, not about whether they exist. Waterfall batches them badly; agile writes them smaller and later; the Unified Process gives us inception, elaboration, construction, transition, which this course borrows on purpose. None of them repeals the life cycle, and eight weeks does not repeal it either.

Here is the whole course in one table. Print it. Tape it somewhere you will see it in Week 5.

Three things to notice. There is no Milestone 4 — Week 4 is a review, and milestone numbers always equal chapter numbers, so the sequence runs 1, 2, 3, then 5. Construction is two weeks out of eight, exactly the fraction the long edition spends; if your mental model of a capstone is “eight weeks of coding,” it is wrong by a factor of four. And every row consumes the row above it: Week 6’s test plan is written against Week 2’s requirement identifiers, and Week 7’s handoff guide is assembled from Week 3’s decision records. Skip a row and you do not save a week — you buy a debt that comes due in a week with no slack, and in this edition no week has slack.

That last point deserves the number. In a sixteen-week course one week is 6.25% of the term. Here it is 12.5%. Falling one week behind is proportionally twice as expensive, and there is no quiet stretch in the middle to absorb it. That is not a scare tactic; it is arithmetic, and it is why Week 4 sits where it does.

1.3 — The Seven Hats, Worn Faster

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 once well.

The eighth hat, the release engineer — “does it run on a machine that isn’t mine?” — is folded into Weeks 3 and 7, where it shows up hard.

In the long edition you change hats between weeks. Here you change them inside a week, sometimes inside an afternoon, and that is the real difficulty of an accelerated course. Two consequences. First, you will default to the developer hat, earlier than you would have. It is the most fun, the feedback is fastest, and it is what you have practiced for three years; under time pressure the pull gets stronger, not weaker. The specific way this ruins an eight-week capstone is that you start typing code in Week 2 “just to try something,” the code becomes the design by accident, and the decision record you write in Week 3 is a rationalization dressed as an argument. Second, the hats disagree, and that is the point. A healthy internal argument in Week 1 of this course sounds like this:

Developer: The brief’s suggested stack is fine, but I’d rather use the framework I’ve been wanting to learn. Architect: That is a second new technology. We already have one. Product owner: The user in this brief does not care what it is written in. Project manager: A new framework costs about eight hours of errors you have never seen, and you have thirty hours of feature construction in total.

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. And the tester hat has to be manufactured the same way: in Week 6 you write tests against requirement identifiers from Week 2, not against the implementation in front of you. You test what you promised, not what you built. In this edition, where your requirements are partly inherited, a mismatch is more likely to be a broken promise than a bug.

Coach’s Note — When you sit down for a 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 4 your log tells you which hat you avoid. Everybody avoids one. Mine was the writer’s for about a decade.

1.4 — The Fast-Start Catalog: Adopt, Adapt, or Bring Your Own

Appendix B holds twelve briefs spanning web and mobile applications, data and analytics, applied AI, developer tooling, security, accessibility, civic and nonprofit software, and education technology. Each ships the same anatomy: the problem and the person who has it, a minimum viable scope that plausibly fits 160 hours, eight to ten drafted functional requirements with acceptance criteria, four to six drafted non-functional requirements with measurable targets, the genuinely hard part, a suggested stack with the reasoning behind it, what to cut first if Week 4 says you are behind, and one way to grow it if you are ahead. There are three legitimate paths through it, and you pick one by Wednesday.

Read the third row honestly before you choose it. Bringing your own project is allowed and welcome — it is often the strongest work in the course — but it costs you the head start, and the head start is real. The long edition spends 60 hours getting from nothing to a written requirements specification (30 in inception, 30 in requirements). This edition does it in 40. Here is where the twenty hours come from — a teaching estimate for projects shaped like these, not a measurement of the industry:

Now the part students misread. That table lists things you did not have to invent. It does not list things you do not have to think about. Nothing in a brief is verified for your situation, and five things remain entirely yours: whether the dependencies work for you today, whether your novelty load is survivable, whether a real human being has this problem in your context, what the hours come to when you estimate them bottom-up, and what you are deliberately not building. Those five are this week’s reps and most of Milestone 1.

Coach’s Note — “I’ll write my own so it’s more impressive” is the most expensive sentence in this course, and it is almost always about the author rather than the user. Nobody grades originality — open the Week-8 rubric in Appendix D and count the lines that reward inventing something nobody has built. Zero. What is graded is whether you carried one system through a full life cycle and handed it to a stranger.

This book will not tell you what to build, but it cannot show you a good requirement, a good decision record, or a good README without showing you some project’s. From here to Week 8 the worked examples come from the same two the sixteen-week edition uses, so the books agree:

PantryPilot — a small web application that lets a household track what food it has, what is about to expire, and what can be cooked from it tonight. One student, one term. Real users (a roommate group), a real data model, one third-party integration (a barcode/product-lookup API), and it has to run on somebody else’s machine. PantryPilot is also brief #1 in the Fast-Start Catalog, which makes it the example you will watch being adapted rather than invented.

TraceLens — a command-line tool that streams a server log file, flags anomalous patterns, and writes a report. No user interface, no accounts, no deployment target beyond “install it and run it.” Almost all of its difficulty is in the data.

Two shapes, one process. Whenever an example appears, ask immediately: what is the equivalent thing in mine?

1.5 — Sizing to 160 Hours: The Arithmetic and the Two-Thirds Rule

Eight weeks at about twenty hours a week is 160 hours — a ceiling you spend against, not a target and not a promise. The first job of a project manager is to know where the money went.

Now the division problem, which is the most valuable ten minutes in this book. Find the hours that are actually hands-on-keyboard feature building:

Call it thirty hours, with a hard ceiling near forty — and understand what borrowing costs, because every hour above thirty comes out of testing and documentation, which carry real points in Week 8 and which nobody has ever finished in a hurry. What does one feature cost? Not “the happy path in an editor.” A feature is a vertical slice: the interface a user touches, the handler behind it, the data access, the validation, the error path when it goes wrong, at least one test, and the line of documentation saying it exists. In a stack you know well, budget 7 to 9 hours a slice; in a stack new to you, 12 to 20. Those numbers do not compress because your term did. Divide thirty by eight and you get the rule this edition runs on.

The two-thirds rule. One hundred and sixty hours buys a project about two-thirds the size of a sixteen-week capstone. That is three to four Must features. Not five, and never more. The single most common way to fail an accelerated course is to attempt a full-length project in half the calendar.

Check it against the long edition and it holds twice: 45 hours of net feature construction there against about 30 here, five or six Musts there against three or four here.

The two-thirds rule, applied to PantryPilot

The left half below is the five-Must scope the sixteen-week edition arrived at after its own cuts — already a disciplined list, and 240 hours pay for it. The right half is the same project sized for eight weeks. Every decision in that column is brief #1’s own: its Must list, in its own what-to-cut-first order. If you adopt the brief, this is the answer you should land on — and if you go somewhere else, the difference is a line in your adaptation record with a reason attached.

Twenty-seven hours against a thirty-hour plan and a forty-hour ceiling: right-sized, with three hours of margin and not one hour more. That margin is why the barcode stays out and why the AI Cook Tonight suggestion stays a Could. The brief is blunt about the pair of them: they are the two expensive optional features, and you can afford at most one, after Week 4 tells you that you are ahead.

Notice which one came off, because students get this backwards every term. The barcode is the expensive part. It is not the hard part. The genuinely hard part of PantryPilot — the brief says so in as many words, and Week 6 will agree with it — is the expiry model and everything that hangs off a date: what the system does with an item that has no printed date, whether “expiring soon” means the same thing for milk and for flour, whose timezone decides when today ends. You cannot cut that one; it is the reason the application exists. Misname your hard part in Week 1 and you spend fourteen hours on an integration while the thing that decides whether anybody uses your software gets designed at midnight in Week 6.

Now look at what the cut in row 2 did, because this is the Week-2 problem arriving early. Brief #1 conditioned one of the two requirements that hang off the scanner and left the other one bare. FR-SCAN-02, the fallback for when the lookup service is down, is already marked “Must if FR-SCAN-01 is adopted; otherwise Won’t” — cut the scanner and it withdraws itself. This one does not:

NFR-PRIV-01 (Should) — No data other than the barcode string leaves the
system to the product-lookup service, and — if FR-REC-01 is adopted — no
data other than item names and expiry dates leaves the system to the
model provider.
Measured by: a unit test over the outbound request builder asserting the
exact field set; a manual capture of one real request.

Read the two halves separately. The second is conditioned — if FR-REC-01 is adopted — so it disappears cleanly when you leave the suggestion out. The first is not. There is no product-lookup service any more, no outbound request to capture, and no field set to assert. That half now describes somebody else’s project, and carried into docs/requirements.md unrepaired it will sit there looking authoritative until Week 6, when you write a test for it and discover you promised something you deliberately chose not to build. That is the signature failure of this edition — and notice that the brief caught one of the two for you and missed the other, which is why “the brief already handled it” is never an answer you get to give. Chapter 2 is where it gets caught; Week 1 is where it gets created, which is why the adaptation record is worth thirteen points on this week’s rubric. And if you brought your own project, the arithmetic is not softer for you — it is harder, because you also have to produce the brief’s contents yourself. Three to four Musts. Thirty hours of features. Run the numbers before you fall in love, not after.

Coach’s Note — When you cut, cut features, never quality. A three-feature project with tests, a README that works, and a real deployment scores far higher in Week 8 than a six-feature project with none of them — and it is also the one you can still fix on the Thursday of Week 7. Scope is the variable. Quality is a constant.

1.6 — Your Engineering System on Day One: Repository, Board, Hours Log

Three artifacts, standing up in the first two days. Together they are your engineering system: the machinery that turns effort into evidence. The long edition builds these in a quiet week with no project attached; you do not have a quiet week, so you build them Monday and Tuesday while the catalog decision runs in parallel. Appendix A is the setup on-ramp — including the browser-only path if your laptop has no administrator rights. Budget two and a half hours, not a day.

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 — tiers change, so confirm current terms before you depend on one. If your institution provides an account, prefer it.) Keep it private now and open it at the end if you like; what you may not do is start over in Week 4 because the history embarrasses you. The history is evidence, and a commit graph with work on twenty-five distinct days is an argument no essay can make. This is the canonical layout, identical to the sixteen-week edition’s — same paths, same names, deliberately, so the two books never disagree. Grouped here by the week each file is written:

capstone/
├── README.md · LICENSE · CHANGELOG.md · .gitignore
├── docs/
│   ├── charter.md · scoping-decision.md · hours-log.csv · ai-usage.md  # THIS WEEK
│   ├── requirements.md · definition-of-done.md · traceability.csv      # Week 2
│   ├── architecture.md · plan.md · risk-register.md                    # Week 3
│   ├── baseline.md                                                     # Week 4
│   ├── test-plan.md · test-results.md · defect-log.md                  # Week 6
│   ├── runbook.md · clean-machine-test.md · handoff.md                 # Week 7
│   ├── retrospective.md                                                # Week 8
│   ├── adr/               # Week 3 onward — one file per decision
│   ├── change-requests/   # Week 4 onward — one CR-nnn-*.md file per request
│   └── review/            # Week 4 — reviewer brief, defect log, signed report, audit
├── src/  tests/           # Week 3 onward
├── script/                # Week 3 — one-word command verbs: setup, test, smoke
└── .github/workflows/     # Week 3 — continuous integration

Every line on the Week-8 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 is missing a home. You are not making a folder structure; you are making a shelf with a labelled slot for each thing you will be graded on, and empty slots are visible, which is the point. Adopt two conventions on day one, because they write two graded artifacts for you later: branch per requirement (fr-014-expiry-warning), merging to main when the tests pass — you do not need to review your own pull request and I will not pretend you do — and the requirement identifier at the front of every commit subject, as in FR-014: warn when an item expires within 3 days, so that in Week 6 you can answer “which commits implemented FR-014?” with one command and the change log mostly writes itself. Pick one identifier convention and never mix: FR-<AREA>-<nn> if your project has clear areas, flat FR-<nnn> otherwise.

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. 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. Cards are verifiable work items, not nouns. Build the backend is not a card — it cannot be finished, cannot be estimated, and cannot be moved to Done without an argument with yourself. This is a 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.

It has a size, a home, and a stopping condition. From Week 2 your cards carry identifiers straight out of docs/requirements.md; this week they are about the engineering system itself and follow the same rules.

The log. docs/hours-log.csv, in the repository, under version control, next to everything else — not a spreadsheet in your downloads folder. Five rules 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, and in a course that grades honesty it is a small lie you have to sign.
2. Write the estimate before you start. One number in estimate_hours, guessed cold. That column is worthless the moment you fill it in afterward — and in eight weeks it is the only calibration data you will ever get.
3. Round to the quarter hour. Precision beyond that is theater.
4. Log blocked time separately. The forty minutes fighting an SDK that would not install is real, it is not development, and it predicts your Week-3 risk register.
5. Log rework, and log the hours that produced nothing. Especially those — rework points at a decision made too early, which is the most useful signal in the file.

A row like 2026-09-07,,,6,,,worked on project,,, tells a grader only that a student was in the building. These rows answer questions:

date,start,end,hours,phase,hat,task,estimate_hours,blocked_hours,notes
2026-09-07,18:30,21:00,2.50,inception,project-manager,scaffold repo + docs tree + board,1.50,0.00,underestimated .gitignore research
2026-09-08,19:00,21:30,2.50,inception,product-owner,read Appendix B; shortlist 3 briefs,2.00,0.00,
2026-09-09,17:00,20:00,3.00,inception,product-owner,adaptation record + bottom-up estimate,2.00,0.50,blocked 30m on product API signup

From those three I can already tell you this student underestimates by roughly 40% and lost half an hour to a vendor signup — two facts that will matter in Week 3 when they build a schedule. The provided script code/week1_check.py does two jobs in four seconds: it audits your repository against the canonical tree above and prints hours by week, by phase, and by hat against the 160-hour budget, with your running estimate-to-actual ratio. Copy it into tools/ and run it every Friday.

python3 tools/week1_check.py --root . --log 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 rather than your project.

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

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

Now the part students misread every term. The six milestones are graded twice. There is a gradebook line called “Milestone 5” — the six together are 25% of your grade, about 4.2 points each — and then everything that milestone produced is graded again inside the 50% final. Read that as double jeopardy and you have misread it: the milestones are the final deliverable, produced one week at a time, and the Week-8 rubric awards points for exactly the artifacts they produce. Skipping Milestone 3 costs you 4.2 points now and the same rubric points again, deferred into a week with no hours left in it, and it starves every downstream week that needed Milestone 3 as an input. The milestones are not assignments stacked beside the final. They are the final, disassembled into six pieces you can actually carry — and you are paid for carrying each one.

So what stops you from discovering that in Week 7? The quizzes. Eight of them, about 1.9% each — small enough that no single one can hurt you, patterned enough that a slide will show. The first reason they exist is ordinary: they check that the vocabulary is in your hands, that you can say what a non-functional requirement is, what an architecture decision record records, what a walking skeleton proves. The second is the real one. They are the early-warning system, and in a course where one week is an eighth of the term the warning has to come fast. When you find yourself guessing on the Week-3 quiz, that is not a quiz problem — that is the late start, ringing a bell while there is still time to answer it.

The full rubric, the pace table, the AI-use policy, and the submission checklist live in Appendix D. Read it this week, and again in Week 4. 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 one portable test, and you should 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 8. If a model chose your database and you cannot say why that one and not the other two, the decision is not yours, the decision record is a forgery, and the Week-4 design review will find it in about ninety seconds. It always does.

The one use that earns its keep this week is pressure-testing a brief. You are about to commit twenty weeks of a normal person’s effort to a project somebody else scoped, and the question you need answered is not “is this good?” but “what would make this too big for me?”

Bad:   "Is this a good capstone project for me?"

Good:  "Here is a project brief: <paste it>. My situation: I know <X and Y>,
        I have never used <Z>, I have about 30 hours of net feature
        construction across 8 weeks, and I work alone. List the ten tasks in
        this brief I am most likely not to have counted. For each, give an
        hour estimate and one sentence on why students underestimate it.
        Do not be encouraging."

Good:  "It is Week 8. This project failed and I am writing the post-mortem.
        Give me the three most likely causes in order of probability, each
        with the earliest week it would have become visible."

Notice what none of that asks for: a new idea, a verdict, or an hour total. It cannot estimate your hours — it does not know how fast you are, what you already know, or that you have a networking exam in Week 5. Any number it gives you describes an average person who does not exist, so use it to find tasks you missed, never to size them. It will also agree with you if you let it: ask leadingly enough and it will cheerfully confirm that a 90-hour scope fits in 30.

docs/ai-usage.md starts this week, from code/ai-usage-template.md: a policy header naming which tools, for what, and what never — then one row per Amber-zone use, all term. “Week 1 — used an assistant to help pick my project” is evidence of nothing. This is evidence of judgment, and it takes ninety seconds:

| 2026-09-09 | Assistant (note the product and model version you actually used)
| Asked: "Argue that a single student with 160 hours cannot finish brief #1
|         as written. Cite the requirements that make it impossible."
| Kept: 4 of the 9 objections it raised, as raw material for my adaptation record.
| Changed: rejected 5 — three assumed a team, two assumed a mobile client the
|          brief never mentions. Rewrote the surviving 4 in my own words with
|          my own hour figures from the bottom-up estimate.
| Verified: checked its claim about the product API's rate limit against the
|          vendor's own page on 2026-09-09; the model's number was wrong.

Where it will fail you, briefly: it will over-scope you, because it is trained to be agreeable; it will write “the system shall be user-friendly,” and Week 2 is largely about repairing that; and it will invent libraries, function signatures, configuration keys, free-tier limits, and license terms that do not exist — the dangerous ones are plausible. Never take a licensing or cost claim from a model. Read the actual text at spdx.org/licenses or the vendor’s own page, and write down the date you read it.

Coach’s Note — Write your AI policy this week while you still feel principled about it. In Week 6, at 1 a.m., with an integration failing and four days to the checkpoint, you will meet the version of yourself who wants to paste the whole repository 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 Week-One Decision Engine

Embedded on this page is The Week-One Decision Engine — the whole of Week 1 in one tool. You pick one of the twelve Fast-Start briefs (or my own idea) and adjust what you intend to change about it: features added or dropped, integrations, technologies genuinely new to you, and whether it needs authentication, persistence, or a deployment somebody else can reach. It returns an hour estimate against the 160-hour budget with a confidence band, a blunt verdict — right-sized, trim two features, or you will not finish this — and then lays the surviving scope across the real eight-week calendar, showing which week each milestone lands in and flagging the week the plan first goes over. A side panel quantifies what the brief already gave you, in hours saved on elicitation and requirements drafting.

Four passes. Do all four.

1. Run your three shortlisted briefs, unmodified. Record each verdict before you have a favorite. Run only the one you like and you have not made a decision; you have made an attachment with a chart next to it.
2. Run your favorite twice — once as you want to describe it, once as you would describe it to somebody who will hold you to it in Week 6. If the two runs differ, the second one is true.
3. Turn on the calendar view and find the week it first goes over. For most students it is Week 6, and it goes over because verification was never in the plan. Look at what the tool cuts to fix it, then decide whether you agree — it cuts by hours, and it does not know which of your features is the hard part.
4. Then estimate the same scope by hand, bottom-up, feature by feature in vertical slices, the way §1.5 does it. That is Rep 9.

Step 4 is the point of the lab. You will then hold two independent estimates produced by different methods, and they will disagree — usually by 20 to 40 percent. That disagreement is the lesson, not a bug. Professional estimating is exactly this: two methods, a gap, and an argument about which assumption differs. Within about 30 percent you have a defensible number; differ by more than a factor of two and one of them is wrong, and you find out which now, in Week 1, while finding out is free. The engine’s model is a heuristic calibrated to one senior working roughly twenty hours a week. It knows nothing about you. Treat it as a skeptical colleague with a spreadsheet, not an oracle.

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 the 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 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 — then he offers two small pictures, the builder and a king weighing whether to go to war, and closes by saying that anyone who does not renounce all that 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 whoever signs up without understanding the price is the one who will quit publicly. The comfort in it is not in our accounting; it is that the cost we could never pay was paid by Christ, and the call still stands.

But notice why the picture works as a picture. Jesus appeals 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 someone who assumes you already recognize it. Three things follow for your work, and the third is why this section sits in Week 1 of an eight-week course rather than Week 2 of a sixteen-week one.

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 row in your hours 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 confident post about an ambitious project beside a repository whose last commit is two months old and whose README says “TODO: add setup instructions.” Your capstone will be public, deliberately, and it is the same discipline you will work under for the rest of your career.

And sometimes counting the cost yields a smaller tower. This is the part an accelerated student most needs and least wants. If the arithmetic says the five-feature version does not fit in 160 hours, the faithful response is not to start anyway and hope the last two weeks are miraculous. It is to build the three-feature version and finish it. That is precisely what the two-thirds rule asks, and it is why the fifth feature comes off the list on the Wednesday of Week 1 rather than the Thursday of Week 7. Cutting something you wanted, early, with your eyes open, is not failure — it is the whole skill the passage commends. An unfinished cathedral glorifies nobody; a finished chapel shelters somebody.

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. “Whatever you do, work heartily, as for the Lord and not for men” (Colossians 3:23, ESV) — and notice what that verse governs. Not the scale of the work. The manner of it. So the question “what does it cost to finish?” is not finally about your grade. Something you finish can serve someone; something you abandon serves no one, however clever the abandoned parts were. The reason Week 7 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 in eight weeks, and finish it.

1.11 — Common Pitfalls

Pitfall: Treating the catalog as a menu to browse rather than a decision to make. Example: It is Wednesday of Week 2 and you are still “narrowing it down to four.” You have now spent 12% of the term choosing — the one thing this edition was designed to eliminate. Fix: Shortlist three by Tuesday, run the Decision Engine on all three, kill two in writing on Wednesday, adapt the survivor Thursday and Friday. If you genuinely cannot choose, take the one with the lowest novelty load; it is the correct answer more often than any other tiebreak.

Pitfall: Adopting a brief’s requirements without an adaptation record. Example: You take the brief’s own cut #2 and withdraw barcode entry, but FR-SCAN-02 still specifies what the system does when a scan returns no match — a failure path for a feature you no longer have. In Week 6 you write a test for a feature you decided not to build, and the specification now reads as a promise you broke. Fix: Every deviation gets a line in the adaptation record naming what changed and which drafted requirements it touches — including “none” if you adopted as-written. Repair the requirements in Week 2 against that list. This is the signature failure of the accelerated edition, and it is preventable in twenty minutes.

Pitfall: Five Must features, because the brief listed five and cutting one feels like quitting. Example: A 48-hour Must list against a 30-hour budget. Nothing is wrong in Week 1; everything is wrong in Week 6, when two features are half-built and the test plan is empty. Fix: The two-thirds rule. Three or four Musts, estimated bottom-up in vertical slices. If the total is over forty, cut a feature — not the tests, not the documentation, and not “some of the error handling.”

Pitfall: Waiting for the project decision before standing up the engineering system. Example: “I’ll make the repository once I know what I’m building.” Friday arrives; there is no repository, no log, and no evidence any work happened at all. Fix: The repository, the board, and the log are stack-agnostic and project-agnostic. Build them Monday, in parallel with reading the catalog. Nothing in Appendix A requires knowing what you are building.

Pitfall: Retro-filling the hours log on Sunday night. Example: Six 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: Letting the assistant make the decision and pasting its answer into your memo. Example: A scoping decision whose tradeoff paragraph is fluent, balanced, and describes a project whose author cannot say which two features they cut, or why. Fix: Use the tool for objections and missed tasks; write the decision in your own words, in the first person, naming what you gave up. Then log the use. A decision you cannot defend out loud is not yours, and Week 4 exists to find out.

1.12 — Where Your Hours Went This Week

A realistic ledger for Week 1. Yours will differ — log what actually happens, not this.

There is almost no slack in that table, and that is not an oversight — it is what twenty hours a week actually looks like. If you finish in eight hours, you did the typing and skipped the thinking. The adaptation record and the estimate are where the judgment lives, and neither is a form.

1.13 — Reps

The reps are in the exercises — twelve of them, and they are not warm-ups beside the milestone. They are the milestone, built one piece at a time, so that by the last rep the charter and the scoping decision mostly write themselves. Preview:

• Rep 1 — create the repository and scaffold the canonical tree in a single commit.
• Rep 5 — shortlist three briefs and run the Week-One Decision Engine on all three.
• Rep 8 — the adaptation diff: everything you are changing about the brief, and which drafted requirements each change breaks.
• Rep 9 — cut to three or four Musts and estimate them bottom-up in vertical slices.
• Rep 12 — write your AI policy, then use it once properly: pressure-test the brief and log the session.

Then take the on-page Check Your Reps quiz. It is the first of eight, together worth 15% — and more usefully, it is the bell that tells you whether you are on pace while there is still time to be.

1.14 — This Week’s Milestone

Milestone 1 — Milestone 1: Charter, Scoping Decision & Engineering System. A repository with the canonical structure, a live board, an honest hours log, a written AI policy, a charter that counts the cost, and a scoping decision naming the brief you adopted, every deviation you made, three or four Must features estimated bottom-up, at least eight things you will not build, the one hard part, and a scope-cut trigger with a real date on it.

That is a heavy first week, and it is heavy on purpose: it merges what the sixteen-week edition spreads across two. The compensation is that when you close the laptop on Friday, the hardest decision in the course is behind you and every remaining week is execution.

1.15 — Coach’s Final Word

Eight weeks from now somebody is going to clone your repository onto a machine you have never touched and try to run your software. Everything between now and then is aimed at that moment.

This week you write no application code. You choose, you commit, and you write down what you chose and why — and if you do it properly you will feel as though you did not accomplish very much, which is exactly the feeling that precedes a capstone that finishes. The students who fail this course are not the ones who picked a boring brief. They are the ones who spent three weeks making sure they picked the right brief, and then had five weeks to build a sixteen-week project.

So: read the catalog. Shortlist three. Kill two, in writing, on Wednesday. Take the survivor, list every single thing you are changing about it, cut until the Must list has three or four things on it, and sign your name at the bottom of a document a stranger could check. Do the arithmetic and let the answer be uncomfortable — it is uncomfortable for everyone, and only some people listen.

Sit down. Count the cost. Then build.

See you on Monday.

Up next: the exercises builds the milestone rep by rep · Milestone 1 is this week’s milestone · then Chapter 2, where the analyst’s hat goes on and inherited requirements get repaired before they can lie to you. Reference: Appendix A (the workbench), Appendix B (the Fast-Start Catalog), Appendix C (the document kit), Appendix D (the grading contract), Appendix E (glossary).