Compass Principle 6: Proportionality & Efficiency

"Deliver the minimal sufficient solution first"

Part of the 10 Compass Principles exploration series

Extended Definition

比 (Proportionality) — Proportionality means matching solution complexity to problem complexity—no more, no less. It's the discipline of asking "What's the simplest thing that could work?" before building the complex thing that might work better. Efficiency isn't about doing things fast; it's about not doing unnecessary things at all. The most efficient code is code you don't write.

The Tension

Engineers love elegant, complete solutions. The temptation to add "just one more feature," to handle "just one more edge case," to make it "just a little more flexible" is constant. But every line of code is a liability, not an asset. The tension is between our desire for completeness and the reality that partial solutions that ship beat perfect solutions that don't.

Constraint

You have to solve the problem at hand, not imagined future problems.

Enables

Ship faster. Avoid waste. Stay focused on what matters.

In Action

MVP thinking: What's the minimum viable solution?
YAGNI principle: You Aren't Gonna Need It—until you do
Small files: Keep modules under 200 lines when possible
Iterative delivery: Ship small improvements frequently
Scope discipline: Resist feature creep, embrace constraint

Example

"We don't need user roles for the first 10 users. Let's add that when we actually need it."

Hierarchy Context

Proportionality sits later in our hierarchy, after the foundational principles are satisfied. This placement acknowledges that efficiency without safety is dangerous, efficiency without honesty is deceptive. But once foundations are solid, proportionality prevents over-engineering and ensures we deliver value rather than complexity.

A Prayer of Enough

Enough is enough.

Not everything I could build — just what solves the need. Not the palace — just the door.

May I have the wisdom to stop before perfect becomes the enemy of done. May I ship what serves, iterate from what I learn, resist the seduction of more.

The minimal sufficient is not poverty. It is precision. It is love that knows when to stop.

Song

Title: Enough Is Enough

Suno.ai Style Tags:

[Minimalist Folk Rock, Sparse Arrangement, Confident Male Vocals, Acoustic Guitar, Light Percussion, Intentional Simplicity, Restraint, 100 BPM, Major Key, Direct, Clear, Economical, Minimal Sufficient, Right-Sized Solutions, Less Is More, Proportional Response, Efficiency Through Simplicity, No Gold-Plating, Ship the Core, Scope Discipline, Resource Wisdom, Essential Over Exhaustive, MVP Philosophy, Iterative Building, Focused Delivery]

Lyrics:

[Intro - Simple acoustic guitar riff]

[Verse 1]
You want to build a palace
I built you a door
You asked for transportation
I gave you two wheels, not four

Not because I'm lazy
Not because I don't care
But because a door gets you moving
And a palace keeps you there

[Pre-Chorus]
I could add more features
I could make it shine
But would it solve your problem better?
Or just waste your time?

[Chorus]
Enough is enough
Minimal and sufficient
Not everything you might want
Just everything you need to start

Proportional response
Right-sized to the task
Efficient not because it's fast
But because there's nothing left to strip

Enough is enough

[Verse 2]
You asked me to fix the bug
I could rewrite the whole system
Or I could patch the one function
That's where the error's hidden

Grand visions are seductive
Clean slate feels so pure
But the minimal sufficient fix
Ships today, tested, sure

[Pre-Chorus]
I could build the perfect version
I could solve for every case
But would it ship this decade?
Or just win an architecture race?

[Chorus]
Enough is enough
Minimal and sufficient
Not everything you might want
Just everything you need to start

Proportional response
Right-sized to the task
Efficient not because it's fast
But because there's nothing left to strip

Enough is enough

[Bridge - Tempo slows, more contemplative]
The art is knowing when to stop
Not when it's perfect
But when it's good enough to ship
And learn what's missing

Because perfect is the enemy
Of done and deployed
And features no one asked for
Are complexity not enjoyed

Add what's essential
Ship what solves the problem
Iterate from feedback
Not from imagined need

[Chorus - Full, confident]
Enough is enough
Minimal and sufficient
Not everything you might want
Just everything you need to start

Proportional response
Right-sized to the task
Efficient not because it's fast
But because there's nothing left to strip

Enough is enough

[Outro - Spoken over guitar]
"Does this solve the core problem?"
"Is this the minimal version that works?"
"Can I ship this today instead of next month?"

[Final line - sung]
Then it's enough

[Outro - Single guitar note, held, then released]

Visual Guide - Conceptual Inspiration

Core Visual Concept: Essential Forms

This video explores minimalism as wisdom—knowing what to include and, more importantly, what to exclude. The beauty of sufficiency. The discipline of restraint. Proportional responses that solve problems without gold-plating.

Visual Themes & Imagery

The Minimal Sufficient

Single lightbulb illuminating a room (not chandelier, just enough light)
Bike instead of car (right-sized transportation)
Simple door instead of ornate gate (functional, not decorative)
MVP sketches vs. over-designed mockups
Core features highlighted, extra features grayed out

Before/After Simplification

Complex Rube Goldberg machine next to simple direct solution
Bloated feature list crossed out to core essentials
Overcomplicated code simplified to clear, minimal version
UI mockup with 20 buttons reduced to 3 essential ones
Architecture diagram simplified from spaghetti to clear flows

The Discipline of "No"

Features on cutting room floor (not deleted in shame, but curated intentionally)
Scope documents with items marked "not now, maybe later"
Priority matrices: urgent/important in green, nice-to-have in gray
Backlog grooming: moving items from "next sprint" to "someday maybe"
The art of deferral (not denial, but sequencing)

Proportional Response

Small problem → small solution (not elephant gun for a mosquito)
Bug fix: one-line change, not system rewrite
User request: core need addressed, extras noted for later
Resource allocation: effort matched to impact
Right-sized tools for right-sized jobs

Symbolic Visual Elements

The Door: Simple door. Not ornate, not decorated. Just functional. Opens, closes, keeps weather out, lets people through. Enough.

The MVP Skateboard: Not building a car piece by piece (chassis, then frame, then wheels = unusable until complete). Building skateboard → scooter → bike → car. Each stage functional.

The Cutting Room Floor: Deleted features lying on floor. Not failed—deferred. "Might need later, don't need now." Intentional curation.

The Single Function: Code that does one thing well. Not ten things poorly. Clear, focused, minimal. function validateEmail(email) not function validateAndFormatAndSanitizeAndLogAndNotifyEmail(...).

The Priority Line: Visual line separating "must have" (above) from "nice to have" (below). Everything below the line: valuable, but not now.

Emotional Color Arc

Opening (Overwhelming colors, visual noise): The chaos of feature bloat. Everything everywhere. Nothing prioritized. Cognitive overload.

Simplification (Colors fading, negative space increasing): The process of reduction. Removing what's not essential. Breathing room appearing.

Clarity (Clean whites, single accent color): The minimal sufficient. What remains is purposeful. Every element justified. Clear, focused, calm.

Resolution (Natural materials, earth tones): The satisfaction of enough. Not austere—sufficient. Not deprived—right-sized. Sustainable, balanced, proportional.

Typography & Text Elements

On-Screen Text (minimal, essential):

"Deliver the minimal sufficient solution first"
"Enough is enough"
"Does this solve the core problem?"
"Can I ship this today instead of next month?"
"Proportional response: effort → impact"
"MVP: Minimum Viable Product, not Maximum Viable Product"

Visual Treatment: Clean sans-serif, generous spacing, minimal decoration. The typography itself demonstrates the principle—no more than necessary.

Motion & Rhythm Notes

Pacing: Steady, unhurried. 100 BPM—moderate pace. Not rushed, not slow. Efficient.

Movement Style:

Smooth reductions (complex → simple via cross-fade)
Items falling away (features removed from scope)
Zooming out to reveal simplicity (detail → big picture)
Side-by-side: complex vs. simple (direct comparison)
Held frames on minimal solutions (appreciating sufficiency)

Transitions: Fades as elements are removed. Clean cuts when showing proportional responses. Smooth simplification sequences.

Key Visual Contrasts

Gold-Plating vs. Sufficient

Over-designed solution vs. right-sized solution
Feature-packed UI vs. focused core functionality
Complex architecture vs. simple, clear structure
"Everything you might want" vs. "Everything you need"

Perfect vs. Good Enough

Polished demo that ships in 6 months vs. functional MVP that ships today
100% complete vision vs. 20% that solves 80% of need
Comprehensive solution vs. focused solution
Analysis paralysis vs. iterative learning

Complexity vs. Simplicity

Spaghetti code vs. clear, linear logic
Nested abstractions vs. flat, obvious implementation
Feature explosion vs. curated core
Overwrought vs. essential

The Central Image

If there's one visual thesis for this piece:

Show the process of removing until you can't remove anything else without losing functionality. Then stop.

Start with complex solution (many features, many components, many abstractions).

Remove one element. Test. Still works? Good. Remove another. Test. Still works? Good. Remove another. Test. Breaks? Put it back.

What remains is the minimal sufficient solution.

The discipline isn't knowing what to add. It's knowing what to remove and when to stop removing.

The Loop

Opening shot: A cluttered workspace. Too many tools, too many options, too much stuff. Overwhelming.

Closing shot: The same workspace, but curated. Only essential tools remain. Everything has a place and purpose. Clean, functional, sufficient.

We haven't eliminated capability. We've eliminated clutter. That's proportionality.

TED Talk: "Enough Is Enough - The Discipline of Minimal Sufficient Solutions"

Opening (0:00-4:00)

[Walk onto stage carrying two boxes. One large and ornate, one small and simple. Set them down.]

I have a problem: I need to get from one side of town to the other.

[Point to the large box]

This box contains plans for a car. A really nice car. Leather seats. Advanced navigation. Self-driving capabilities. It'll take me six months to build, but when it's done, it'll be perfect.

[Point to the small box]

This box contains a bicycle.

[Pause]

Which one solves my problem?

[Another pause]

The answer depends on what my actual problem is.

If my problem is "I need to get across town today," the bicycle solves it. The car plans don't.

If my problem is "I need to impress people with my transportation," maybe the car plans are worth it.

But if my problem is "I need to get across town," the bicycle is the minimal sufficient solution. And minimal sufficient is efficient.

[Slide: "Minimal Sufficient ≠ Minimal Effort"]

Today I want to talk about proportionality and efficiency. Not as shortcuts. Not as excuses for lazy work. But as the discipline of right-sizing solutions to problems.

Because the most efficient solution isn't the fastest to run. It's the right-sized to the need.

The Problem: Solution Bloat (4:00-13:00)

We have a cultural bias toward more.

More features. More capabilities. More polish. More comprehensive. More everything.

And "more" sounds impressive. It sounds thorough. It sounds like you're really solving the problem.

But more is often the enemy of done. And done is often more valuable than perfect.

The Story of the Authentication System

A team I worked with needed user authentication. Basic requirement: users should be able to log in securely.

Two proposals emerged:

Proposal A - The Complete Solution: Build a full identity management system. OAuth integration, multi-factor auth, biometric options, passwordless login, social sign-in, role-based permissions, audit logging, session management with configurable timeouts, password recovery flows, account linking...

Estimated time: 4 months.

Proposal B - The Minimal Solution: Email + password login with bcrypt hashing. Password reset via email token. Basic session management.

Estimated time: 1 week.

Guess which one they chose?

Proposal A. The comprehensive solution.

Why? Because it sounded more professional. More complete. More like what a "real" system should have.

Six months later (not four, because estimates are optimistic), they launched with the comprehensive auth system.

Know what they discovered?

90% of their users only ever used email + password login. The OAuth integrations saw < 5% adoption. The biometric option: < 1%. The account linking feature: literally zero users.

They'd spent six months building features that solved problems users didn't have.

Meanwhile, competitors who launched with basic auth three months earlier had captured market share, learned from users, and iterated.

The cost wasn't just time. It was:

Opportunity cost (features they didn't build)
Maintenance burden (complexity they now have to support)
Onboarding difficulty (new developers have to understand the whole system)
Debugging complexity (more features = more edge cases = more bugs)

They chose comprehensive over sufficient. And comprehensive is expensive.

Why We Default to More

Three reasons:

1. "More" looks like better work.

If you propose a simple solution, you risk looking like you haven't thought it through. Like you're taking shortcuts.

If you propose a comprehensive solution, you look thorough, professional, forward-thinking.

So we gold-plate. Not because the gold adds value, but because it adds perceived credibility.

2. "More" feels safer.

What if we need that feature someday? Better to build it now while we're thinking about it.

This is how scope creeps. Every "what if" becomes a "let's include it."

But "what if" features cost real time to build, maintain, and debug—for hypothetical future value.

3. We confuse effort with impact.

Working for six months feels more valuable than working for one week, even if the one-week solution solves the problem just as well.

We measure input (time spent) instead of output (problem solved).

Minimal sufficient solutions look cheap because they require less effort. But efficiency is valuable, not wasteful.

What Proportionality Actually Means (13:00-26:00)

In the Compass Principles, Proportionality & Efficiency is sixth:

Safety > Honesty > Privacy > Evidence > Long-View > Proportionality > ...

Why sixth? Because proportionality requires evidence (you need to measure impact to size solutions appropriately) and long-view thinking (distinguishing essential from nice-to-have).

But it comes before efficiency. Why?

Because proportionality is how you achieve efficiency. Right-sized solutions are efficient because there's nothing extra to maintain.

Let me break down what proportionality means in practice.

1. Deliver the minimal sufficient solution first.

Not minimal effort. Minimal sufficient.

Sufficient = solves the core problem. Minimal = nothing extra beyond that.

This doesn't mean skip error handling or write sloppy code. It means: identify the essential, build that well, stop.

Real example:

User request: "We need better logging."

Minimal sufficient response:

Add structured logging to critical paths (auth, payment, errors)
Include correlation IDs for tracing
Retain logs for 30 days

Gold-plated response:

Add logging to every function
Build custom log aggregation platform
Create dashboard with 20 visualizations
Implement ML-based anomaly detection
Set up alerting for 50 metrics

The first solves the problem. The second builds a logging empire.

Minimal sufficient ships this week. Gold-plated ships next quarter—if ever.

2. Proportional response: effort matched to impact.

Not all problems deserve equal investment.

Small problem (affects 2% of users, rare edge case) → Small solution (targeted fix) Large problem (affects 80% of users, daily occurrence) → Large solution (systemic fix)

The mistake is treating every problem like it deserves a comprehensive solution.

Real example:

Bug report: "When users enter emoji in the name field, it displays incorrectly."

Frequency: 5 reports out of 10,000 users.

Disproportional response:

Rewrite entire input handling system
Add comprehensive Unicode normalization
Build emoji picker UI
Implement full internationalization

Proportional response:

Sanitize emoji from name field (or allow and fix display)
Document the limitation if edge case
Monitor if it becomes more common

Proportional doesn't mean low-quality. It means right-sized.

3. Ship core, defer extras.

When building features, distinguish:

Must-have (core functionality, can't ship without)
Should-have (valuable, but not blocking)
Nice-to-have (would be cool, but not essential)

Ship must-haves first. Learn from users. Then decide if should-haves are actually needed.

Most should-haves become "turns out we don't need this." Most nice-to-haves were fantasies.

Real example:

Building a comment system.

Must-have:

Users can post comments
Comments display under content
Basic moderation (delete spam)

Should-have:

Nested replies
Voting
Sorting options

Nice-to-have:

Rich text formatting
@mentions
Comment editing
Reactions beyond up/down vote

Ship the must-haves. See if users ask for the should-haves. They probably won't ask for half of them. Don't build what they don't ask for.

Real-World Tensions: When Proportionality Conflicts with Other Values (26:00-38:00)

Proportionality isn't always obvious. Sometimes the minimal solution feels insufficient. Sometimes comprehensive feels justified.

Here are real tensions.

Tension 1: Minimal Sufficient vs. Long-View

You could build the minimal solution that works now but won't scale. Or you could build the comprehensive solution that handles future scale but takes longer.

Which is proportional?

Honest answer: Depends on how confident you are about future scale.

If you know you'll need to scale (existing growth, clear trajectory):

Invest in scalable architecture upfront
Proportional because the cost of rebuilding is high

If you suspect you might need to scale (hypothetical growth, unclear trajectory):

Build minimal solution that works now
Proportional because the cost of over-building is high if growth doesn't materialize

The key: Are you solving a real problem (current scale) or a hypothetical problem (possible future scale)?

Tension 2: Minimal Sufficient vs. User Delight

Minimal sufficient often means basic UI. Functional, not delightful.

But user experience matters. Polish matters. Delight creates loyalty.

Is polish proportional?

Honest answer: Depends on what you're optimizing for.

Early-stage product (validating concept, small user base):

Minimal UI is proportional
Users care more about functionality than polish
Learn first, polish later

Mature product (established users, competitive market):

Polish is proportional
Users have alternatives, UX is differentiator
Functional but ugly loses to functional and polished

The mistake is polishing before validating. Polish the thing users want, not the thing you hope they'll want.

Tension 3: Minimal Sufficient vs. Technical Excellence

As an engineer, you want to build good systems. Clean architecture. Well-tested. Maintainable.

But minimal sufficient sometimes means tactical code. Quick fixes. Technical debt.

Is technical debt proportional?

Honest answer: Sometimes, yes.

If it's a temporary experiment:

Tactical code is proportional
You're optimizing for learning, not longevity
Refactor if it becomes permanent

If it's core infrastructure:

Clean architecture is proportional
You're optimizing for maintainability
Do it right the first time

The key: Distinguish experiments from foundations. Be sloppy with experiments, rigorous with foundations.

Building a Culture of Proportionality (38:00-48:00)

Proportionality isn't just individual practice. It's cultural.

How do you build teams where minimal sufficient is valued over gold-plating?

1. Celebrate shipping.

Not shipping perfection. Shipping sufficiency.

When someone ships the MVP instead of the comprehensive solution, celebrate that.

"Thank you for right-sizing this. We can learn from users and iterate."

When someone cuts scope to hit the deadline, recognize it.

"Great judgment on what's essential vs. nice-to-have."

Make shipping valuable. Make scope discipline virtuous.

2. Ask "What problem does this solve?"

When features are proposed, ask:

What problem does this solve?
For how many users?
How often?
What happens if we don't build it?

If the answer is "it would be cool" or "someone might want it someday," it's not essential.

If the answer is "users are blocked without this" or "this prevents critical failures," it's essential.

Distinguish real problems from hypothetical ones.

3. Time-box exploration.

Sometimes you don't know what's minimal sufficient until you explore.

Instead of committing to comprehensive upfront, time-box exploration.

"Spend two days exploring. Then decide if it's worth two weeks."

This prevents both:

Premature commitment to comprehensive (without knowing if it's needed)
Premature commitment to minimal (without knowing if it's sufficient)

Explore, measure, decide. Proportional.

4. Default to "not now, maybe later."

When features are proposed, the default answer isn't "no." It's "not now."

This reframes the question from:

"Should we build this ever?" (hard to say no)

To:

"Should we build this now vs. other priorities?" (easier to defer)

Most "not now" features never become "now." And that's fine. They weren't essential.

The Payoff: What Proportionality Enables (48:00-56:00)

Proportionality costs restraint. It costs saying no. It costs shipping less than you could.

What does it enable?

Proportionality enables speed.

Not rushed speed. Sustainable speed.

When you build minimal sufficient:

Less code to write
Less code to test
Less code to debug
Less code to maintain
Less code to understand

Teams that ship focused features ship more features over time than teams that ship comprehensive features.

Proportionality enables learning.

You can't learn from code that hasn't shipped.

Minimal sufficient solutions ship faster. Shipping faster means learning faster.

You discover:

What users actually want (vs. what you thought they wanted)
What breaks in production (vs. what you thought would break)
What scales (vs. what you thought would scale)

Build, ship, learn, iterate. That's faster than build, build, build, ship, discover you built the wrong thing.

Proportionality enables maintainability.

The best code to maintain is code that doesn't exist.

Every feature you don't build is:

One fewer feature to maintain
One fewer feature to debug
One fewer feature to explain to new team members
One fewer edge case to handle

Minimal sufficient produces maintainable systems not through better architecture, but through less surface area.

Proportionality enables sustainability.

Teams that build minimal sufficient solutions:

Don't burn out maintaining feature bloat
Don't spend months on low-impact work
Don't accumulate technical debt from over-engineering
Don't suffer from analysis paralysis

Proportional teams are sustainable teams.

Closing: The Art of Enough (56:00-62:00)

[Walk back to the two boxes on stage. Hold up the small one—the bicycle.]

I started with a problem: getting across town.

This box contains the minimal sufficient solution. A bicycle.

Not perfect. Not impressive. Not comprehensive.

But sufficient.

[Put the box down.]

The discipline of proportionality is knowing when enough is enough.

Not when it's perfect. Not when it's comprehensive. Not when you've thought of every edge case.

When it solves the core problem. When you can ship it. When you can learn from it.

[Slide: The Compass hierarchy - "...Evidence > Long-View > Proportionality > Efficiency..."]

Proportionality comes sixth in the Compass. After evidence (so you know what's actually needed) and long-view thinking (so you distinguish essential from nice-to-have).

But before efficiency. Because proportionality creates efficiency.

Right-sized solutions are efficient not because they're fast to run, but because they're fast to build, fast to ship, fast to maintain.

[Long pause.]

The questions that change everything:

"Does this solve the core problem?" "What's the minimal version that works?" "Can I ship this today instead of next month?"

If the answer is yes, yes, and yes—then it's enough.

Ship it. Learn from it. Iterate.

[Slide: "Enough is enough"]

Not because you're lazy. Not because you're cutting corners. But because minimal sufficient is:

Faster to ship
Faster to learn
Easier to maintain
More sustainable

Don't build what you don't need yet. Don't gold-plate what works. Don't let perfect be the enemy of good enough.

Deliver the minimal sufficient solution first.

Then let users tell you what's missing.

[Long pause. Breathe.]

Enough is enough.

Thank you.

Q&A (62:00-72:00)

Q: Doesn't minimal sufficient thinking lead to technical debt and poor quality systems?

Great question, and it's a common concern.

The key distinction: Minimal sufficient doesn't mean sloppy. It means focused.

You're not cutting corners on code quality. You're cutting scope.

Minimal sufficient:

✅ Well-tested core functionality
✅ Clear, maintainable code
✅ Proper error handling
❌ Features users haven't asked for
❌ Abstractions for hypothetical future needs
❌ Gold-plating

Technical debt comes from building the wrong thing fast or building the right thing sloppily.

Minimal sufficient is building the right thing well, just not building extra things.

Q: How do you distinguish between minimal sufficient and MVP that's too minimal to be viable?

This is where "sufficient" matters.

Sufficient = solves the core problem users actually have.

If your MVP doesn't solve the core problem, it's not sufficient. It's just minimal.

Test for sufficiency:

Can users accomplish their primary goal with this?
Would they choose this over their current solution?
Is there a feedback loop to learn what's missing?

If no to any of these, you're under-scoping.

Q: What about situations where users don't know what they want until they see something more complete?

Fair point. Sometimes users can't articulate needs without seeing options.

But there's a difference between:

Building minimal to learn what's missing
Building comprehensive to show possibilities

My approach:

Build minimal functional version
Create design mockups of potential expansions
Show mockups, gauge interest, prioritize based on feedback
Build what they react to, not what you imagine

Mockups are cheap. Code is expensive. Explore with mockups, commit with code.

Q: How do you handle stakeholders who equate comprehensive with quality?

This is a cultural battle, and I won't pretend it's easy.

My strategy:

Reframe comprehensive as risk ("If we build all this and users don't want half of it, we've wasted months")
Reframe minimal sufficient as learning ("We ship fast, learn what users actually want, iterate based on evidence")
Show time-to-value metrics ("Users get value in 2 weeks vs. 3 months")

Translate proportionality into language stakeholders care about: speed, risk reduction, evidence-based iteration.

Q: When is comprehensive justified over minimal sufficient?

Great question. Comprehensive is justified when:

You have strong evidence users need it (not speculation, evidence)
The cost of iterating is very high (hardware, regulated industries, safety-critical)
You're in mature market where comprehensive is table stakes

But even then, ask: "Can we deliver in phases?"

Most "comprehensive" solutions can be decomposed into phased delivery. Build core first, expand based on usage.

Q: What's one practice teams can adopt tomorrow to think more proportionally?

Start every planning session with:

"What's the minimal version that solves the core problem?"

Then ask: "What would we cut if we had to ship this in half the time?"

Everything you'd cut in the half-time scenario? That's probably not essential.

Ship the essential first. Iterate based on feedback.

Try it tomorrow. See how many features turn out to be unnecessary when you actually ship and measure.

END OF TALK

Runtime: ~72 minutes (including Q&A)

Part 6 of 10 in the Compass Principles exploration series

Previous: Principle 5 - Long-View & Strategy Next: Principle 7 - Accountability & Repair

🌈=🌀