Failure Mode 03 — Scope Creep & Perfectionism¶
Probability: 55% (higher for engineers)
What It Is¶
Scope creep is the expansion of a project’s requirements beyond what is achievable in the allocated time. Perfectionism is the refusal to ship an artifact that works but isn’t “good enough.” These are the same failure mode with different self-narratives: scope creep tells you the project needs more features; perfectionism tells you it needs more polish. Both produce the same result: nothing ships.
For engineers, this failure mode is particularly acute. You have professional standards. You know what production-quality code looks like. You cannot un-know it. So when you build a learning project, the gap between your aspirational standard and your current output is uncomfortable — and the temptation is to close that gap by doing more work rather than by accepting that learning artifacts are allowed to be rough.
“Perfect is the enemy of deployed. And deployed is what builds the portfolio.”
Why This Happens in ML Specifically¶
ML projects have a seductive infinite-improvement loop: the model can always be better, the dataset can always be larger, the architecture can always be more sophisticated. There is no natural stopping criterion. You have to impose one — and if you don’t, the project expands forever.
The second factor: the ML research culture valorizes novelty and improvement. Reading papers all day trains you to see what’s wrong with any approach. This critical faculty is valuable for research. It is toxic for building learning projects on a 13-month timeline. A working bigram language model is not an embarrassment — it is a concrete artifact that proves you understand the mechanism.
What It Looks Like at the Failure Point¶
Three sprints in, you have:
One project that has been “almost done” for six weeks
A GitHub repository with one commit: “initial setup”
A project spec document that has expanded from “train a classifier” to “train a classifier with custom attention, on a cleaned dataset I’ll build myself, with a FastAPI serving layer and a monitoring dashboard”
A growing sense that you’re working hard but not progressing
A portfolio with zero shipped artifacts
This is scope creep + perfectionism. The project became the obstacle rather than the vehicle.
Symptoms¶
Symptom |
Description |
|---|---|
“I’ll push when it’s ready” |
No commits for >5 days on an active project |
Feature addition before shipping |
Adding new requirements before the original ones are met |
Architecture redesign after 80% completion |
“I realized the whole approach is wrong” (used more than once) |
Comparison to production systems |
Measuring your learning project against deployed products |
“I want to understand it better first” |
Used to delay starting implementation |
Inability to define “done” |
No acceptance criteria written at sprint start |
Early Warning Signals¶
Sprint planning: You cannot write a crisp “Definition of Done” for the sprint’s main project.
Day 5 of Week 1: You have added requirements to the sprint project that weren’t in the original plan.
Week 2 start: The project is “not ready to share” even with yourself.
Sprint end: You deliver “90% done” for the second consecutive sprint.
Month 2: Your GitHub shows commits on 3 different project repositories, all incomplete.
Mitigation¶
The 72-Hour Ship Rule¶
If a project hasn’t shipped a working version in 72 hours of active work time, scope it down — immediately.
This rule is not about quality. It is about forcing scope decisions. If 72 hours of work hasn’t produced something that runs and does the core thing, the scope is wrong. Not you — the scope.
What “shipped” means for learning projects:
It runs without errors
It does the core thing you intended
You can demonstrate it in 3 minutes
It is committed to GitHub with a README
That’s it. No production requirements. No polish requirements.
The Scope Ladder¶
When a project is growing beyond its original scope, use this ladder to cut back to the minimum viable version:
Rung |
Question |
Action |
|---|---|---|
1 |
What is the single core mechanism I’m trying to demonstrate? |
Define it in one sentence |
2 |
What is the minimum code required to demonstrate that mechanism? |
Write that, nothing else |
3 |
Does it produce a reasonable output for a known input? |
Yes → ship it. No → debug only the core |
4 |
What are the “nice-to-have” features? |
Move them to a future sprint |
Example — Scope Ladder in practice:
Sprint goal: “Build a sentiment classifier.”
Week 1, Day 3: You’ve added a custom tokenizer, a data augmentation pipeline, and a REST API layer.
Scope Ladder:
Core mechanism: model takes text, outputs positive/negative
Minimum code: load dataset → vectorize with existing tokenizer → train simple model → evaluate accuracy
Reasonable output: >70% accuracy on test set
Nice-to-have: custom tokenizer, API layer → future sprint
Ship the minimum version. Add the rest next sprint if it still matters.
The Definition of Done Template¶
Write this before you start any project. If you can’t fill it out, the project isn’t scoped yet.
Project: [name]
Core mechanism to demonstrate: [one sentence]
Inputs: [what it takes in]
Outputs: [what it produces]
Success criterion: [specific, measurable]
Time box: [hours of active work allocated]
Done when: [the three things that must be true for this to be "shipped"]
Out of scope (explicitly): [the things you are choosing not to build]
Escalation Trigger¶
If three consecutive sprints end without a single shipped artifact (committed, running, demonstrable), invoke the reset protocol.
At the reset: current project is paused. One week. One tiny project. One commit by end of week. No features. Proof of life only.
The Reframe¶
Your learning projects are not products. They are not research contributions. They are evidence of understanding. Evidence of understanding does not need to be beautiful. It needs to be real.
A working bigram language model with clean code and a README is evidence. An unfinished transformer with 47 uncommitted files is not.
Ship the rough thing. You can always build a better version later. You cannot build a reputation on projects that exist only on your local machine.