The Question That Changes Everything
Or: Why Asking Engineers “How Can We Do This Faster?” Is the Worst Question You Can Ask
There’s a conversation happening in sprint planning meetings across the world right now that’s slowly poisoning your codebase. A product owner, well-intentioned and under pressure, leans across the table and asks: “How can we get this done faster?”
It seems like a reasonable question. Time is money. Deadlines matter. Stakeholders are waiting. But this single question, repeated across thousands of decisions, is the root cause of more technical debt than any architectural mistake you’ve ever made.
Kent Beck, the father of Extreme Programming and a man who has thought more deeply about software development than most of us have had hot dinners, offers an alternative. Instead of asking “how can we do this faster?”, ask engineers “how can we do this in a more simple way?”
The difference in wording is subtle. The difference in outcomes is profound.
As Albert Einstein (allegedly) put it: “Everything should be made as simple as possible, but not simpler.” He was talking about physics, but he might as well have been describing the architecture decisions you made last Tuesday at 4 PM when you were just trying to get the build passing before the demo.
The Speed Trap
When you ask engineers how to do something faster, you’re implicitly authorizing a set of trade-offs that will come back to haunt you. Faster usually means: skip the tests we don’t have time for, copy-paste that code rather than abstracting it, add a feature flag we’ll “definitely” clean up later, hardcode this value because it’s “just for now.”
Each of these decisions feels cheap in the moment. The economist John Kenneth Galbraith observed that “the conventional view serves to protect us from the painful job of thinking.” And nothing is more conventional than optimizing for speed when you’re under pressure.
But here’s the thing: when you ask how to make something simpler, you often get the speed for free — just without the accompanying technical debt.
Simplicity forces engineers to ask different questions: Do we actually need this feature? Can we solve the customer’s problem with fewer moving parts? What can we remove rather than add?
The Human Bias Toward Addition
Here’s where it gets genuinely fascinating. Researchers at the University of Virginia conducted a series of experiments that should terrify every product owner and engineering leader on the planet. Led by Leidy Klotz, the team discovered that when people are asked to improve something — whether it’s a Lego structure, an essay, a recipe, or a travel itinerary — they overwhelmingly default to adding rather than subtracting.
In almost every instance across their experiments, people were more likely to add elements to solve problems. They pile on features, introduce new parameters, create additional abstractions. The only time subtraction became the default was when the researchers deliberately inserted something obviously wrong — like a grilled cheese sandwich with liver.
The implications for software development are staggering. Every time we sit down to solve a problem, our brains are wired to reach for more: more code, more abstraction, more configuration, more options, more flexibility for a future that may never arrive.
As Klotz notes: “Overlooking subtraction may mean that people are missing out on opportunities to make their lives more fulfilling, their institutions more effective and their planet more livable.” Replace “planet” with “codebase” and you have a perfect description of how we’ve been building software for the past three decades.
The Two Diseases of Engineering
I see two distinct failure modes in engineers, and they’re both related to misunderstanding simplicity.
The first is over-engineering. We’ve all seen it: the “perfect architecture” that takes six months to build, supports fifteen use cases that nobody asked for, and collapses under its own weight the moment a real customer touches it. Everything must be DRY and reusable. Every method needs an interface. Every decision needs an abstraction layer.
You know what drives this? Usually the fear of being caught out in the future. “What if we need to swap databases?” “What if the business model changes?” “What if we need to support multiple currencies?”
Ron Jeffries, co-founder of XP, put it simply: “Always implement things when you actually need them, never when you just foresee that you will need them.” This is the YAGNI principle — You Ain’t Gonna Need It — and it’s one of the most violated principles in our industry.
Solve the problem. Write the test automation that prevents regression. Make it performant. Make it readable. Ship it. Don’t overthink the problem.
The second disease is the patch-on-top mentality. These engineers understand that over-engineering is bad, but they swing to the opposite extreme. Rather than fixing root causes, they add workarounds. Rather than refactoring, they patch. The code accumulates layer upon layer of special cases, each one a monument to some past crisis that nobody took the time to properly resolve.
Following simplicity means you’ll hit problems sooner — that’s the whole point. The key is recognizing that when you hit these problems, it’s time to refactor, not time to patch. Now you have a working system that is solving a customer’s problems. Now you have the context to understand what the code actually needs to do. Now is the time to make it better.
The Fowler Principle
Martin Fowler, through Kent Beck’s influence, articulated something that every engineer should tattoo somewhere visible: “For each desired change, make the change easy (warning: this may be hard), then make the easy change.”
This is the opposite of how most teams work. When faced with a hard change, we fight through the difficulty, wrestle the code into submission, and ship the feature with battle scars visible in the commit history. The next person who needs to make a change faces exactly the same difficulty, plus the additional complexity we introduced in our struggle.
Beck’s approach inverts this: if it’s hard to implement something, first refactor the code to make it easy to implement. Then make the easy change. The refactoring becomes a gift to your future self and everyone else who will touch this code.
Jessica Kerr gave a lovely metaphor for this: “It’s like I want to go 100 miles east but instead of just traipsing through the woods, I’m going to drive 20 miles north to the highway and then I’m going to go 100 miles east at three times the speed I could have if I just went straight there.”
The resistance to this approach usually comes from people who think the refactoring is “extra work.” But the refactoring isn’t extra — it’s the actual work. The feature you’re shipping is just the visible part.
When To Do What
So here’s the framework we use at Agoda, and it’s served us well:
Before you build: Don’t plan for problems you don’t have yet. YAGNI isn’t just an acronym — it’s a survival strategy. The things you’re planning for may not happen. Requirements change. Business priorities shift. That elegant abstraction you spent a week building might never get used.
While you build: Solve the customer’s problem with the least complexity possible. Every line of code is a liability. Every abstraction is a tax on future readers. When you feel the urge to add something “just in case,” resist.
When you hit a wall: This is the critical moment most engineers get wrong. You’ve found a problem with your code structure. Maybe a new feature doesn’t fit cleanly. Maybe a change is harder than it should be. This is not the time to patch on top. This is the time to step back and ask: how can I make this code better before I proceed?
The key insight is that problems with your code structure reveal themselves through the difficulty of change. Treat that difficulty as information. It’s telling you something important about your design.
The Simple Rules
Kent Beck’s four rules of simple design have survived for decades because they work:
Passes the tests. The code works. This is table stakes.Reveals intention. Someone reading your code can understand what you were trying to do.No duplication. Everything is said once and only once.Fewest elements. No unnecessary classes, methods, or abstractions.Notice the order. The code has to work first. Then it has to be understandable. Then you eliminate duplication. And only after all that do you minimize the overall structure.
Most engineers I meet have inverted this hierarchy. They start by minimizing elements (premature abstraction), then worry about duplication (copy-paste paranoia), occasionally think about clarity, and sometimes check if it works.
As a Product Engineer you take responsibility for the feature not the code, you own the code and the code is what creates and supports the feature.
The Conversation Change
Here’s my challenge to every product owner reading this: for the next sprint, don’t ask your engineers how to do things faster. Ask them how to do things simpler.
You’ll find something remarkable happens. Engineers who were defensive about timelines start engaging with the problem differently. Features that seemed like two-week efforts suddenly shrink to three days. Not because anyone’s working harder, but because you’ve removed the permission to over-complicate.
And here’s my challenge to every engineer: when you hit resistance in your code, don’t reach for the patch. Ask yourself: what is this resistance telling me about my design? How can I make this code better before I proceed?
The legendary basketball coach John Wooden said, “If you don’t have time to do it right, when will you have time to do it over?” In software, we somehow convinced ourselves that doing it wrong now and fixing it later is a viable strategy. It isn’t. The “later” never comes, or when it does, the cost of fixing it has multiplied beyond recognition.
The Bottom Line
Simplicity isn’t the absence of effort — it’s the presence of clarity. It’s not about doing less work; it’s about doing the right work. Every line of code you don’t write is a line you don’t have to maintain, test, document, or debug at 3 AM when it inevitably breaks.
The University of Virginia research shows we’re biologically wired to add rather than subtract. That means simplicity requires active resistance against our natural tendencies. It requires asking different questions. It requires changing the way we talk about work.
So the next time someone asks “how can we do this faster?”, try a different question: “How can we do this in a more simple way?”
You might be surprised how often the answer is “by doing less.”
Now, if you’ll excuse me, I need to go delete some code. There’s an abstraction from 2023 that’s been “adding value” for long enough.