Páginas

▼

Friday, June 20, 2025

YAGNI and the Value of Learning: An Additional Premise

For years, I’ve been applying—almost without realizing it—an extension of the YAGNI principle that I want to share. It’s become part of how we work as a team, a “gut feeling” we’ve refined through experience, and I believe it’s worth making explicit.

Beyond Traditional YAGNI

YAGNI (You Aren't Gonna Need It) is a fundamental principle reminding us not to implement features just because we think we might need them in the future. It's a powerful defense against overengineering and unnecessary complexity.

But there are situations where the premise shifts. Sometimes we know we’re going to need something. It’s not speculation—it’s a reasonable certainty based on product context, business needs, or the natural evolution of the system.

In those cases, our response is not to implement the full solution just because “we know we’ll need it.” Instead, we ask ourselves:

Is there a smaller version of this that lets us learn earlier?

The Value of Learning as a Decision Criterion

The key is to evaluate the learning value of each intermediate step. Not every small step is worth taking—only those that provide meaningful insight into:

  • Actual user behavior
  • The technical feasibility of our approach
  • The validity of our assumptions about the problem
  • The real impact on the metrics we care about

When the cost of that small step is lower than the value of the learning it brings, it’s almost always worth it. This is a practical application of Lean Startup principles to technical development.

Nonlinear Risk: Why Small Steps Matter

There’s another factor reinforcing this approach: risk doesn’t grow linearly with the size of the change. A change that’s twice as big doesn’t carry twice the risk—it carries exponentially more risk.

Small steps allow us to:

  • Catch issues while they’re still manageable and easy to fix
  • Validate assumptions before investing more resources
  • Maintain the ability to pivot without major cost (optionality)
  • Generate more frequent and higher-quality feedback

How We Apply This in Practice

We’re quite radical about this approach. We aim to get product changes to users within 1–1.5 days, and within that cycle, we ship even smaller technical changes to production. These micro-changes give us valuable information about the “how” while we continue refining the “what.”

Our mental process is almost instinctive: whenever a need arises, we consider multiple options—some that others might call “hacky”—and always choose the smallest possible step, no matter how strange it may seem.

We use techniques like Gojko Adzic’s hamburger method to slice functionality, but we go even further. We constantly ask ourselves:

  • “Can we start with a hardcoded version to validate the UX?”
  • “What if we begin with a manually uploaded CSV before building an automated integration?”
  • “Can we simulate this feature with manual config while we learn the real flow?”
  • “What if we do it just for one user or a specific case first?”

This isn’t about being naive about future needs. It’s about being smart about how we get there. Each micro-step gives us signals about whether we’re going in the right direction, both technically and functionally. And when something doesn’t work as expected, the cost to pivot is minimal.

This obsession with the smallest possible step not only reduces risk, it also accelerates real learning about the problem we’re solving and the behavior of the solution we’re implementing.

Connection with Other Premises

This way of working naturally aligns with other guiding principles in our approach:

  • Postpone decisions: Small steps allow us to delay irreversible choices until we have more information
  • Small safe steps: We work incrementally to reduce risk and increase learning
  • Software as a means: We focus on impact, not on building the most complete solution upfront
  • Optimize for feedback: We prioritize fast learning over perfect implementation, because we know we don’t have all the answers—we need to discover them

A Premise in Evolution

Like all the premises we use, this isn’t universal or applicable in every context. But in software product development, where uncertainty is high and the cost of mistakes can be significant, it has proven extremely valuable.

It’s part of our default way of working: we always look for the smallest step that lets us learn something useful before committing to the full step. And when that learning has value, it’s almost always worth the detour.

Have you experienced something similar in your work? How do you evaluate the trade-off between implementing something fully and taking intermediate steps to learn?

References

at

No comments:

Post a Comment