When Models Mislead
Overview
Models that were useful become dangerous when the context changes. "Move fast and break things" is a reasonable approach at a 10-person startup with no users. At a 10,000-person company serving millions of customers, breaking things means breaking trust, revenue, and regulatory compliance. The model didn't become wrong. The context changed, and the model didn't update.
The models in your head have expiration dates. The mental frameworks, rules of thumb, and engineering principles you rely on were formed in specific contexts. When those contexts shift, the models that served you well can actively mislead you.
How Models Expire
A model becomes misleading when:
1. Scale changes
What works at 100 users doesn't work at 1,000,000 users.
What works for a 5-person team doesn't work for a 50-person team.
2. Stakes change
What works for a side project doesn't work for a payment system.
What works pre-revenue doesn't work post-IPO.
3. Domain changes
What works for web apps doesn't work for embedded systems.
What works for B2C doesn't work for B2B enterprise.
4. Technology changes
What was true about databases in 2010 may not be true in 2026.
What was expensive in compute is now cheap. What was cheap
in storage is now even cheaper.
5. Team changes
What works with experienced engineers doesn't work with
a team of new graduates. What works with co-located teams
doesn't work with distributed teams.
Models That Expire with Scale
"Premature Optimization Is the Root of All Evil"
The model (Donald Knuth, 1974):
Don't optimize code until you've profiled it. Most optimization
effort is wasted on code that isn't the bottleneck.
When it's useful:
You're building a new feature. Traffic is low. You don't know
what the bottleneck will be. Writing clear, simple code and
optimizing later is the right approach.
When it misleads:
You have 1 million active users. Your database query takes
500ms. You know it's the bottleneck because users are
complaining and your monitoring shows it clearly. Someone
says "premature optimization is the root of all evil" and
argues against optimizing until a formal profiling session.
At scale, some optimizations are not premature. They are
overdue. The model was about not guessing at bottlenecks.
When you have monitoring showing you the bottleneck, acting
on that data is not premature — it is engineering.
The updated model:
Don't optimize without evidence. When you have evidence,
optimize immediately. The quote includes an important
qualifier that people forget: Knuth said "about 97% of the
time." The other 3% is when you know the critical path and
should optimize it from the start.
"Don't Repeat Yourself" (DRY)
The model:
Every piece of knowledge should have a single, unambiguous
representation. Duplicated code is a bug waiting to happen.
When it's useful:
Two functions do the same thing. When the requirement changes,
you update one and forget the other. DRY prevents this class
of bugs.
When it misleads:
Two microservices have similar data validation logic. Someone
extracts it into a shared library. Now both services depend on
the library. Updating the library requires coordinating deploys
across both services. The shared library becomes a coupling
point that slows down both teams.
At the microservice scale, some duplication is preferable
to coupling. Two copies of a validation function that evolve
independently are cheaper to maintain than a shared library
with coordinated releases.
The updated model:
DRY applies within a service or module. Across service
boundaries, the cost of coupling often exceeds the cost
of duplication. Prefer duplication over wrong abstraction.
"Move Fast and Break Things"
The model:
Speed matters more than quality. Ship quickly, learn from
failures, iterate.
When it's useful:
Pre-product-market-fit. You don't know what to build.
Building the wrong thing perfectly is worse than building
the right thing imperfectly. Speed of learning is the
most important metric.
When it misleads:
You have 10 million users. "Breaking things" means:
→ Customers can't access their accounts
→ Financial transactions fail
→ Data is lost or corrupted
→ Regulatory violations with real legal consequences
→ Engineers spend more time firefighting than building
The model was designed for a context where breaking things
was cheap (no users, no revenue, no compliance). In the
new context, breaking things is extremely expensive.
The updated model:
Move fast with confidence. Speed comes from good testing,
feature flags, progressive rollouts, and automated rollbacks.
Not from skipping safeguards.
Models That Expire with Team Size
"Just Talk to Each Other"
The model:
Communication problems are solved by talking more.
Skip the process, skip the documentation, just have
a conversation.
When it's useful:
5 people in a room. Everyone has context on everything.
A 5-minute conversation is faster than a 30-minute
meeting with an agenda.
When it misleads:
50 engineers across 8 teams in 3 time zones. "Just talk
to each other" means:
→ Nobody knows who to talk to
→ The same conversation happens 15 times with different people
→ Decisions are made verbally and forgotten
→ New team members have no way to learn past decisions
At team scale, documentation and process are not bureaucracy.
They are how information scales beyond what conversations can carry.
The updated model:
Talk to each other AND write it down. Conversations for
exploration, documents for decisions. The document is not
a replacement for the conversation. It is the artifact
that makes the conversation's conclusions available to
people who weren't in the room.
"Hire Smart People and Get Out of Their Way"
The model:
Good engineers are self-directed. Give them a problem
and they'll figure out the solution. Managers should
remove blockers, not direct work.
When it's useful:
A small team of senior engineers working on a well-defined
problem. They have context, they have skill, and they
know how to coordinate with each other.
When it misleads:
A growing team with a mix of experience levels, working
on ambiguous problems with cross-team dependencies.
"Get out of their way" becomes:
→ Junior engineers floundering without direction
→ Senior engineers duplicating effort because nobody
is coordinating priorities
→ Cross-team work stalling because nobody owns the
coordination
→ Architecture diverging because there's no shared vision
The updated model:
Hire smart people, provide clear direction, create
frameworks for coordination, and invest in mentoring.
Autonomy works when people have enough context to make
good decisions independently. Providing that context
is leadership, not micromanagement.
Models That Expire with Stakes
"Ask Forgiveness, Not Permission"
The model:
It's faster to do the thing and fix it if it goes wrong
than to ask for approval and wait.
When it's useful:
Low-stakes, reversible decisions. Changing a UI color.
Adding a logging statement. Trying a new library in a
non-critical service.
When it misleads:
Deploying a database schema change without review.
Changing the authentication flow without security signoff.
Modifying a data pipeline that feeds financial reports.
When the stakes are high and the decision is hard to reverse,
"ask forgiveness" becomes "cause a crisis that could have
been prevented with a 10-minute conversation."
The updated model:
Ask forgiveness for low-stakes, reversible decisions.
Ask permission for high-stakes, irreversible decisions.
Know which category your decision falls into.
"Ship It and Iterate"
The model:
Good enough today is better than perfect next month.
Ship early, get feedback, improve.
When it's useful:
Building a new feature where user feedback is more
valuable than your assumptions. Shipping a basic version
and learning from usage is the right strategy.
When it misleads:
Shipping a payment integration that handles the happy
path but not failure cases. Shipping an API without
rate limiting. Shipping a data export feature that
works for 100 records but crashes at 10,000.
"Ship and iterate" was designed for features where
imperfection means a suboptimal user experience.
Not for features where imperfection means data loss,
security vulnerabilities, or financial errors.
The updated model:
Ship and iterate on user experience. Do not ship and
iterate on correctness, security, or data integrity.
Those must work before the first user touches them.
Recognizing When Your Models Are Stale
Warning signs that a model needs updating:
1. The model's advice conflicts with your experience
You follow the model and things go wrong. Not once,
but repeatedly. The model may no longer fit your context.
2. People who disagree with the model are succeeding
Another team ignores "don't repeat yourself" and ships
faster with fewer bugs. Maybe DRY doesn't apply in
your distributed architecture.
3. You're using the model as a justification, not a tool
"We can't add tests for this because YAGNI."
When a model is used to defend decisions you've already
made rather than to evaluate decisions you're considering,
it has stopped being a thinking tool and become a shield.
4. The context has changed significantly
New scale, new team size, new domain, new technology.
Any of these can invalidate a model's assumptions.
5. The model hasn't been questioned in years
Models that are "obvious" and "everyone knows" are the
most dangerous. They persist long after their context
has expired because nobody thinks to question them.
Updating Your Models
Step 1: Identify the model and its original context
"Move fast and break things" was born at early Facebook.
Small team, no revenue, rapid experimentation required.
Step 2: Identify your current context
You are a 200-person engineering organization with
paying customers, SLAs, and regulatory requirements.
Step 3: Find the mismatch
The model assumes breaking things is cheap.
In your context, breaking things is expensive.
Step 4: Modify or replace the model
Replace "move fast and break things" with
"move fast with confidence through testing, flags,
and progressive rollouts."
Step 5: Communicate the update
Share the updated model with the team. Explain why
the old model no longer applies. Give concrete examples
of how the new model changes decisions.
A Catalog of Expiring Models
Model Useful When Misleading When
──────────────────────────────────────────────────────────────────────────
"Move fast and break things" Pre-product-market-fit Serving paying users
"Premature optimization Building new features Known bottleneck
is evil" with monitoring data
"DRY" Within a service Across service
boundaries
"Just talk to each other" 5-person team 50-person organization
"Hire smart people and Senior team, clear Mixed experience,
get out of their way" problem ambiguous problems
"Ship and iterate" UX improvements Correctness, security,
data integrity
"Ask forgiveness, not Low-stakes, reversible High-stakes,
permission" irreversible
"YAGNI (You Aren't Gonna Speculative features Known requirements
Need It)" you're ignoring
"Monolith first" Greenfield with small Team of 100 engineers
team stepping on each other
"Microservices" Large org, clear Small team with
boundaries unclear boundaries
Common Pitfalls
- Applying models from your last job without adjusting for your current context: The practices that worked at a startup may not work at an enterprise, and vice versa. Every model carries invisible assumptions about team size, scale, stakes, and culture. Examine those assumptions when you change environments.
- Quoting models as authority instead of reasoning from principles: "Knuth said premature optimization is evil" is not an argument. It is an appeal to authority. The argument is "we don't know where the bottleneck is, so optimizing now would likely be wasted effort." When the argument doesn't hold, the quote doesn't save it.
- Refusing to update models because they worked before: Past success makes models sticky. "We've always done it this way and it worked" ignores that the conditions for success may have changed. What worked is less important than why it worked, because the why tells you whether it will still work.
- Swinging to the opposite extreme: When "move fast and break things" stops working, the temptation is to adopt "move slowly and break nothing." The right update is nuanced: "move fast with safeguards." Overcorrecting creates a new set of problems.
- Not examining shared assumptions: The most dangerous stale models are the ones the whole team believes without discussion. "We don't need to write tests for this because it's simple" or "our users won't care about latency" are models that may have expired. Surface them. Question them. Update them.
Key Takeaways
- Models have expiration dates. The mental frameworks and rules of thumb you rely on were formed in specific contexts. When scale, stakes, team size, or domain changes, the models must change too.
- "Premature optimization is the root of all evil" expires when you have monitoring showing a known bottleneck. "DRY" expires at microservice boundaries. "Move fast and break things" expires when breaking things costs money and trust.
- Watch for warning signs: the model's advice conflicts with your experience, people who ignore the model are succeeding, or you're using the model as justification rather than as a thinking tool.
- Update models explicitly. Identify the original context, compare it to your current context, find the mismatch, and modify the model. Share the update with your team so everyone is operating from the same mental framework.
- The goal is not to discard all models but to hold them lightly. Use models as starting points for thinking, not as substitutes for it. When reality contradicts the model, update the model, not your perception of reality.