Project Portfolio

The fifteen builds: size, effort, dependencies, scope tiers, and the one sentence that says why each exists.

Table of Contents

• Master Table
• Effort and Size Classification
• The Three Scope Tiers
• What Each Project Teaches That No Other Project Teaches
• Language Assignment
• The Deliverable Every Project Produces
• Reading This Track's Project Pages
• References

Master Table

Effort and Size Classification

The size rule

No project may grow beyond its class ceiling. A Medium project at week 11 is not a diligent Medium project, it is an undeclared Large one, and it is stealing weeks from a project later in the plan that you have not yet met and therefore cannot defend. The enforcement is mechanical: at the class ceiling you stop, ship whatever passes the exit criteria, and write the rest into the extension section of the report. See the two-week stall rule.

How the hour estimates were built

Each figure is the sum of its project's milestones, each estimated independently, then sanity-checked three ways:

1. Against the allocation. A project of H hours should show ~0.15H reading, ~0.45H implementation, ~0.20H experiments, ~0.10H writing, ~0.10H debugging. If a project's milestone list implies 0.8H of implementation, the estimate is wrong or the scope is.
2. Against known reference implementations. P01 is calibrated against nanoGPT (~300 lines of model code); P04 against the LevelDB paper's component list; P05 against the MIT 6.5840 lab sequence, which takes competent graduate students most of a semester at higher intensity than 11 h/week.
3. Against the 4× rule. Boehm's cone of uncertainty says early estimates are routinely off by 4× in either direction. These are not off by 4× because they are milestone-level rather than project-level, but assume ±30% on any individual project and expect the errors to partially cancel across fifteen.

Where these estimates are most likely wrong, stated in advance so you can check:

• P05 (143 h) is the most likely to overrun. Distributed debugging has no floor. The fault injector is scheduled first specifically to bound it.
• P12 (121 h) is the second. If you choose the bootable option and hit a toolchain problem, you can lose two weeks to something that teaches you nothing. Budget a hard "switch to the user-space option" decision at week 3 of the project.
• P08–P10 (176 h combined) are the most likely to underrun, because they are closest to your existing expertise. If you finish early, do not add scope — advance the schedule and bank the weeks against P12.

The Three Scope Tiers

Every project defines three versions. This is the single most important structural device in the plan, because it converts "when am I done?" from a judgement call into a lookup.

Minimum viable implementation (MVI). The smallest artifact that still exhibits the mechanism being studied. Must be genuinely educational on its own: an LSM engine without compaction is an MVI (it still teaches WAL, memtable, SSTable, recovery); an LSM engine that keeps everything in RAM is not, because the mechanism under study is precisely what happens when it does not.

Standard implementation. MVI plus the features that make the project's core experiments possible. This is the target. Exit criteria are written against this tier.

Optional research extension. The interesting thing you will want to do. It is locked until the standard tier passes its exit criteria, and it may be skipped entirely without affecting any later project. Nothing downstream ever depends on an extension — that is what makes it optional in a way that survives contact with a busy quarter.

Worked example — Project 4

If week 9 arrives and leveled compaction is half-finished, you ship size-tiered only, you write "leveled compaction not implemented; the read-amplification comparison is therefore against published figures rather than my own" in the report, and you move on. That is a completed project with a stated limitation. It is worth far more than a twelfth week.

What Each Project Teaches That No Other Project Teaches

If you ever need to cut, cut by asking which unique lesson you are willing to lose.

Language Assignment

Rationale and the full argument in Languages. The summary:

Four languages across 34 months, each assigned once and not revisited on a whim. You already know Python and Go. Rust is the one real learning cost, and it is paid across P11-I (Small, W16–20) where the project is easy enough that the language is the only hard part — that scheduling is deliberate.

The Deliverable Every Project Produces

Not negotiable, and identical across all fifteen:

1. A repository that a stranger can clone and run. One command to build, one to test, one to reproduce the headline benchmark. If it needs a paragraph of setup prose, it is not reproducible.
2. A technical report (REPORT.md), 1,500–4,000 words, following templates/report.md, containing a section titled "What I Expected And Did Not Get". That section is scored and may not be empty.
3. A research-notebook entry per experiment, following templates/notebook.md.
4. A benchmark artifact: the raw sample data (not just summaries), the script that produced it, and the environment block.
5. A scorecard self-assessment, twelve categories, with evidence named per score.

The first three take about 10 hours of the project's budget combined. That is the 10% writing allocation, and it is the part that converts a build into a portfolio.

Reading This Track's Project Pages

Every project page has the same eighteen sections, in the same order, so you can jump straight to the one you need:

Why This Project Matters      Concepts To Study          Expected Difficulties
Prerequisites                 Primary-Source Readings    Scope Boundaries
Duration and Size             Experiments                Deliverables
Central Technical Questions   Benchmarks and Metrics     Exit Criteria
Architecture                  Correctness Tests          Extension Ideas
Implementation Milestones     Failure Tests              Connections

Plus, at the top of each, the fourteen-step loop instantiated for that project — what "naive design" and "predicted failure point" concretely mean for this build. Read that section, then close the page and write your own naive design before reading the architecture section. The architecture section is deliberately placed after the loop for that reason.

References

• Boehm, B. W. Software Engineering Economics. Prentice-Hall, 1981. The cone of uncertainty underlying the ±30% claim.
• Brooks, F. P. No Silver Bullet — Essence and Accident in Software Engineering. IEEE Computer 20(4), 1987. The essential/accidental distinction is what the scope tiers are trying to separate: MVI is essence, everything else is negotiable.
• Athanassoulis, M. et al. Designing Access Methods: The RUM Conjecture. EDBT 2016. The read/update/memory trilemma referenced in P04's unique lesson.
• Ousterhout, J. A Philosophy of Software Design, 2nd ed. Yaknyam Press, 2018. Deep modules and the argument that interface simplicity is worth implementation complexity — the standard against which each project's API is judged.
• Karpathy, A. nanoGPT. github.com/karpathy/nanoGPT, 2022. The calibration reference for P01's size estimate. Read the code after you write yours, not before.
• MIT 6.5840 (formerly 6.824) Distributed Systems lab sequence. The calibration reference for P05.