Define “Good” With 4 Numbers

 

Define “Good” With 4 Numbers






The simplest habit that makes engineering calmer

Most engineering debates are not about code.

They’re about undefined expectations.

“This feels slow.”
“This is not reliable.”
“This is too expensive.”
“This isn’t scalable.”

The problem is not disagreement.
The problem is that nobody defined what “good” actually means.

Over time, I’ve started doing something simple before building anything meaningful:

We define four numbers.

Not twenty metrics.
Not vague goals.
Just four numbers that align engineering, product, and leadership.

1. Latency Target

What should this feel like for a normal user?

Not what is technically possible.
Not what is “acceptable in theory.”
What should the experience actually feel like?

If you do not define this early, you end up optimizing randomly.

Is 800ms fine?
Is 300ms expected?
Does this flow need sub-100ms?

When we define the latency expectation upfront, architecture decisions become easier:

  • Caching becomes intentional

  • Query design becomes thoughtful

  • External dependencies are evaluated more critically

Performance stops being reactive.

2. Error Budget

How much failure is acceptable before we stop shipping and stabilize?

No system has zero errors.

But very few teams define how much instability is tolerable.

An error budget forces discipline.

If we exceed it:

  • Feature velocity slows

  • Reliability becomes priority

  • Root causes are addressed

This prevents the slow decay where teams keep adding features while the foundation quietly weakens.

It shifts reliability from emotional debate to measurable accountability.

3. Cost Guardrail

How much are we willing to spend to support this system?

Cloud costs do not spike because engineers are careless.

They spike because there was no boundary.

If cost is not part of the design discussion:

  • Overprovisioning becomes normal

  • Staging runs 24/7 unnecessarily

  • Dependencies multiply without scrutiny

A cost guardrail does not limit ambition.

It forces smart architecture:

  • Right-sizing infrastructure

  • Efficient data storage

  • Intentional caching

  • Eliminating waste

Engineering decisions improve when cost is visible.

4. On-Call Expectation

How often is it acceptable to wake someone up?

This number changes behavior dramatically.

If the expectation is:

  • “Rarely” → systems get more redundancy

  • “Never for minor issues” → alert quality improves

  • “Only for user-impacting failures” → noise gets removed

Without defining this, teams slowly normalize chaos.

And chaos eventually leads to burnout.

Why These Four Numbers Matter

When these four are written down, something powerful happens:

  • Trade-offs become obvious

  • Discussions become objective

  • Priorities stabilize

  • Quality becomes measurable

Instead of arguing whether something is “good,”
you ask:

Does it meet our defined numbers?

If yes, ship.
If not, improve.

Calm engineering is not accidental.
It is structured.

The Real Shift

Many teams optimize for:

  • Speed

  • Features

  • Architecture elegance

Fewer teams optimize for:

  • Clarity

  • Guardrails

  • Sustainability

The best systems I’ve worked on were not the most complex.

They were the ones where expectations were explicit.

If You Do One Thing

Before your next major feature or service, define:

  • A latency target

  • An error budget

  • A cost guardrail

  • An on-call expectation

Put those four numbers in writing.

Everything else becomes easier.

Closing Thought

Engineering feels chaotic when “good” is undefined.

It feels disciplined when “good” is measurable.

What is one number your current project absolutely needs to define?

__________________________________________________________________________________

Written by Sharath Chandra Odepalli

LinkedIn 

Comments

Post a Comment

Popular posts from this blog

Stop Building: Why Less Is More in Software Development

  Stop Building: Why Less Is More in Software Development The biggest waste in software isn't bugs, technical debt, or slow deployments. It's building features nobody uses. Research reveals a sobering truth: 45% of features are never used, 19% are rarely used, and only 36% are used regularly or often. Translation: nearly half of engineering effort creates zero value. Think about that for a moment. Half of all the sprints, all-nighters, code reviews, bug fixes, and deployment stress—wasted on features that users will never click. This isn't a small problem. It's the silent killer of engineering productivity and product success. The Three Forces Driving Waste Force 1: Engineers Love Solving Hard Problems We're wired to seek complexity. When faced with a problem, we instinctively reach for the sophisticated solution. A simple notification system? Why not build a real-time WebSocket infrastructure with Redis pub/sub and horizontal scaling? A basic reporting feature? Obv...
Read more

Clarity: The Most Underrated Skill in Technology

Image
There’s a quiet truth in the engineering world that people only discover after years of writing code, leading teams, and shipping systems: Your value in tech is measured far less by what you build and far more by how clearly you think. This isn’t intuitive. In a field obsessed with new frameworks, new architectures, and now new AI models—clarity feels almost… old-fashioned. But here’s the irony: The more complex the industry becomes, the more clarity becomes a competitive advantage. Complexity Isn’t Hard. Simplicity Is. If you’ve spent long enough in engineering, you’ve seen this pattern: A senior engineer writes code that works—but nobody else wants to maintain it. A team ships a feature—but half the customers don’t understand how to use it. A brilliant system is designed—but onboarding takes three meetings and an internal wiki. We call these “engineering problems,” but they’re actually  clarity problems . The hardest parts of building software aren’t the algorithms, the databases...
Read more

The Transparency Era: What California's New AI Law Means for Tech Builders

Image
  Yesterday marked a pivotal moment in technology regulation - one that signals we've crossed a threshold from which there's no turning back. Governor Gavin Newsom signed  SB 53 , California's first major AI transparency law, requiring the world's largest artificial intelligence companies to publicly disclose their safety protocols and report critical incidents within 15 days. This isn't just another piece of legislation lost in the noise of regulatory bureaucracy. It's a watershed moment that redefines the social contract between technology companies and the public they serve. From Voluntary to Mandatory: The Shift Nobody Saw Coming For years, AI safety has been a gentleman's agreement. Companies like OpenAI, Anthropic, Google, and Meta have made voluntary commitments to safety testing and responsible development. They've published research papers, formed ethics boards, and publicly discussed the importance of alignment and safety. But voluntary commitm...
Read more