Why Should We Ask Why? The Power of Curiosity in Software Engineering

by SanjewaPhilosophy of Programming
Front
Back
Right
Left
Top
Bottom
WHY???

The Question That Changes Everything

Have you ever fixed a bug only to see it resurface a week later? Or implemented a feature that users never actually needed? The difference between good and great software engineering often comes down to one simple word: Why.

In the fast-paced world of software development, asking “why” repeatedly—typically five times—helps identify the underlying systemic cause instead of just symptoms. This isn’t just about debugging code; it’s about building better systems, fostering innovation, and creating real value for users and businesses.

FIVE WHYS
The Five Whys

Toyota's Gift to Software Engineering

The Five Whys technique was developed by Sakichi Toyoda at Toyota in the 1930s and became the standard root cause analysis method across manufacturing, healthcare, software development, and anywhere recurring problems drain productivity.

But here’s the thing: the “five” is a guideline, not a rule—simple problems might need 2-3 whys, while complex ones might need 7-8 or more.

A Real-World Software Example

Let me show you how this works in practice. Here’s a scenario many of us have faced:
Problem: The application crashes during heavy user load.

Why #1: Why does the software crash during heavy user load?
→ The server becomes overwhelmed with concurrent requests.

Why #2: Why does the server become overwhelmed?
→ The server’s capacity wasn’t scaled to handle high traffic.

Why #3: Why wasn’t the server scaled properly?
→ The team didn’t perform load testing during development.

Why #4: Why didn’t we do load testing?
→ Load testing wasn’t included in the project scope.

Why #5: Why wasn’t it in scope?→ We lacked the resources and expertise for load testing.

Root Cause
The root cause reveals that crashes were caused by the absence of load testing in the project’s initial scope and the lack of access to necessary resources and expertise.
The Fix
 
Make load testing a standard part of the development process—not a band-aid solution for the symptom.
INNOVATION
Why "Why" Drives Innovation

Beyond Bug Fixes

Questioning the Status Quo
Some of the biggest leaps in innovation have come from questioning the status quo—questions like “What if we did it differently?” and “Why are we doing this in the first place?” lead to breakthroughs.

Think about it: Every major innovation in software—from Git to Docker to Kubernetes—started with someone asking “Why are we doing it this way?”
The Growth Mindset Connection
Software engineers with the right mindset approach challenges with a problem-oriented view, seeking innovative solutions rather than being deterred by obstacles. They understand that development isn’t just about writing code; it’s about solving meaningful problems.

As a developer with years of experience, I’ve learned that great engineers don’t just jump into coding—it’s about asking the right questions and solving problems effectively, sometimes without writing a single line of code.
DAILY WORK
Asking "Why" in Your Daily Work

Practical Applications

Code Reviews
When reviewing code, instead of just checking syntax:
🐍 
# Instead of accepting this without question:
def process_data(data):
    time.sleep(2)  # Wait for processing
    return transform(data)

# Ask: Why the 2-second sleep?
# Better solution after asking "why":
def process_data(data):
    # Poll for completion with exponential backoff
    return await_processing_complete(data)
Architecture Decisions
Before choosing a microservices architecture, ask:
  • Why do we need microservices?
  • Why not a monolith first?
  • Why this particular service boundary?
  • Why now, not later when we have more data?
Feature Development
If the only answer to “why perform this task” is “because someone said so,” that’s not enough—understanding the purpose ensures it aligns with broader project goals.
CURIOSITY

Building a Culture of Curiosity

For Individual Contributors
By asking questions, you’re not showing ignorance; you’re showing initiative and demonstrating that you care about understanding, that you’re engaged, and that you want to learn.
 
Pro tip: Frame your questions constructively:

- Don't: "This design is confusing."

- Do: "Why did we choose this approach over X? I want to understand the tradeoffs."
For Leaders and Managers
Embracing a growth mindset allows you to recognize that questions are essential to the learning process and that it’s okay not to know everything.

Create psychological safety where team members feel comfortable asking:
  • Why are we prioritizing this feature?
  • Why this tech stack over alternatives?
  • Why are we measuring success this way?
For Business Stakeholders
Understanding why engineers ask “why” helps align technical and business goals:
Business: "We need this feature by next week."

Engineer: "Why next week specifically?"

Business: "We have a demo with a major client."

Engineer: "Why do they need this specific feature?"

Business: "They mentioned needing better reporting."

Engineer: "Why not show them our existing analytics with enhanced filters?"

Result: Delivered in 2 days instead of a rushed week of development.
art-of-explaining-complex-tech-simply
AVOID

Common Pitfalls to Avoid

Stopping Too Soon
Everyone treats the symptom—the broken part—instead of asking why it broke, and this cycle continues because teams don’t identify fixable failures in systems.
The Blame Game
Teams sometimes rush through analysis because they’re uncomfortable with questions—if your culture doesn’t support honest answers, the Five Whys won’t work regardless of how well you understand the technique. Focus on systems, not people.
Analysis Paralysis
If you need longer than 90 minutes for Five Whys analysis, consider whether it’s the right tool or if you need more comprehensive root cause analysis.
SHERLOCK MIND
Making It Second Nature

The Detective Mindset

One of the most valuable skills a tester can develop is the ability to think like a detective—driven by curiosity, persistence, and an analytical approach to uncovering software defects that might otherwise go unnoticed.

This applies to all engineers, not just testers. If you want to dive deeper into the detective approach to coding, check out my previous post on Sherlock Holmes Programming: Detective Methods for Coders where I explore how classic detective techniques can transform your debugging and problem-solving skills. Approach every task as an investigation.

APPLICATIONS
The Business Case

ROI of Asking "Why"

For Startups and Entrepreneurs
  • Reduced technical debt:
    Fixing root causes prevents compound interest on bad decisions
  • Faster iteration:
    Understanding "why" helps you pivot intelligently
  • Better product-market fit:
    Asking "why do users need this?" leads to genuine value
For Established Companies
  • Lower maintenance costs:
    Over time, continuous incremental investments and improvements compound, improving productivity and freeing up time previously lost to fire-fighting breakdowns
  • Improved team morale:
    Engineers feel empowered when their questions matter
  • Competitive advantage:
    A product mindset puts emphasis on customers and value, rather than proxy metrics and activities, helping enable key DevOps goals
MEASURABLE

Measurable Impact

Studies show that teams practicing root cause analysis:
  • Reduce recurring bugs by up to 70%
  • Decrease time-to-resolution by 50%
  • Improve code quality scores significantly

Explore project snapshots or discuss custom web solutions.

More About Me
ACTION PLAN
Your Action Plan

Getting Started

Week 1: Personal Practice
  • Pick one bug or task
  • Write down five "why" questions before coding
  • Document your findings
Week 2: Team Integration
  • Introduce Five Whys in retrospectives
  • Practice with one recent production issue
  • Create a shared learning document
Week 3: Process Embedding
  • Add "Root Cause" field to bug tickets
  • Include "Why" discussions in design reviews
  • Celebrate good questions in standups
INTEREST
Your Action Plan

The Compound Interest of Curiosity

Asking “why” isn’t just a technique—it’s a mindset that compounds over time. Every question you ask:
  • Deepens your understanding
  • Prevents future problems
  • Builds better systems
  • Inspires your team
  • Creates lasting value
The engineers who consistently ask “why” don’t just write code; they craft solutions that stand the test of time. They don’t just fix bugs; they prevent entire classes of problems. They don’t just follow instructions; they innovate.

As you continue your journey in software engineering, remember: the most powerful tool in your toolkit isn’t a framework, a language, or a methodology. It’s your curiosity.
Start today. Pick one task. Ask why five times. See where it leads you.

By repeating why five times, the nature of the problem as well as its solution becomes clear.

Sakichi Toyoda Founder of Toyota Industries and creator of the Five Whys technique

Thank You for Spending Your Valuable Time

I truly appreciate you taking the time to read blog. Your valuable time means a lot to me, and I hope you found the content insightful and engaging!
Front
Back
Right
Left
Top
Bottom
FAQ's

Frequently Asked Questions

Frame questions with genuine curiosity: "I want to understand the reasoning behind X so I can learn" works better than "Why would we do X?" Use collaborative language like "Can you help me understand why..." or "I'm curious about the decision to..."

If your culture doesn't support honest answers, the Five Whys won't work regardless of how well you understand the technique. Start small—ask "why" in one-on-ones first, demonstrate value through better solutions, and gradually build psychological safety.

The "five" is arbitrary—some problems need two iterations, others need ten. You'll know you've revealed the root cause when asking "why" produces no more useful responses, and you can go no further.

Five Whys is most effective when used to resolve simple or moderately difficult problems—it may not be suitable for complex or critical problems that could have multiple causes. For complex issues, consider Fishbone diagrams, FMEA, or comprehensive root cause analysis.

Short-term, skipping "why" seems faster. Long-term, it's slower because you'll revisit the same issues repeatedly. As a software engineer, it is vital to make conscious decisions at every step—this deliberate approach ensures that every action is purposeful and aligned with your goals. Even spending 15 minutes on "why" can save hours later.

Blogs

Related Blogs

Comments are closed