Photo by Joseph James: Zoologischer garten — bahnhof

The Magic of Asking “Why?” in Software Engineering

Joseph James (JJ)
5 min readAug 14, 2023

--

In the booming world of software engineering, where every keystroke contributes to creating sophisticated systems, there’s one tool that doesn’t require coding skills, yet holds unparalleled significance: the question “why?”. This three-letter inquiry, though seemingly small, possesses a deep-rooted power, Often missed among the technical terms and complicated algorithms.

Imagine a room filled with artists, each with a palette of colors. Some start painting immediately, holding on to the initial impressions, while a few take a moment to ask, “Why am I choosing this color?”. Those who think about are not just concerned with the shade; they’re diving into the essence of their creation, ensuring each stroke resonates with their envisioned masterpiece.

Software engineering is much like this room. While the immediate task might be coding, it’s the underlying “why?” that dictates the direction, quality, and effectiveness of the final product. It’s the difference between constructing a bridge and building one that will stand the test of time. Both serve a purpose, but the latter ensures longevity, relevance, and real-world impact.

1. Getting to the Heart of Issues

A problem surfaces, and the instinctive reaction might be to dive headfirst into finding a fix. But, by pausing to ask “why?”, we step back, gain perspective, and dissect the challenge layer by layer. It’s like approaching a puzzle, understanding each piece and its place before attempting to solve it. This depth ensures we’re addressing the real concern and not just masking symptoms, ultimately leading to more sustainable and effective solutions.

Scenario: A mobile app crashes every time users try to upload an image.

Immediate reaction: Let’s fix the crash.

But when we ask “why?”, we dig deeper: Why does it crash only during image uploads? Maybe there’s an issue with the image processing library, or perhaps the server doesn’t handle certain image sizes well. By understanding the root, the solution becomes clear and comprehensive.

2. Making Sense of Needs

Stakeholders have demands, but why? The beauty of this question lies in its ability to sift through surface-level requirements and dive into the underlying motivations. By doing this, we align our solutions with the true objectives, ensuring what we build genuinely resonates with user needs. This tailored approach not only improves user satisfaction but also ensures that our work has a meaningful impact.

Scenario: A client demands a face recognition feature for users to login into the a food delivery app.

Instead of blindly implementing, asking “why?” leads to clarity: Why does the client feel this feature is essential? Is it to improve user engagement, address support queries, or something else? Knowing the purpose can guide the design and functionality of the face recognition feature.

3. Picking the Right Features

Software design can be overwhelming with the countless features we can add. Asking “why?” for each potential addition becomes crucial. Does it enhance user experience? Does it align with our objectives? With each query, we evaluate the genuine value and relevance of a feature, ensuring we build streamlined products that users love and understand, devoid of unnecessary complexities.

Scenario: A team considers migrating Retrofit to Ktor feature to their productivity tool.

By asking “why?”, they evaluate the real need: Will users find value migrating to Ktor? Is it to aid performance or readablity? Such reflection ensures the feature is not just a gimmick but a meaningful addition.

4. Deep Dives in Code Reviews

Beyond the surface of syntax and structure lies the logic and reasoning of a piece of code. When we review and ask “why was it done this way?”, we gain insight into the coder’s mindset. This allows us to appreciate different strategies, share best practices, and ensure that the team benefits from shared knowledge and diverse perspectives, enriching the overall coding environment.

Scenario: During a review, a piece of code seems unnecessarily complicated.

Instead of dismissing it, inquiring “why was it done this way?” might reveal that the coder was catering to a specific edge case or future functionality. This fosters understanding and shared learning.

5. Smart Design Choices

Software design is a dance between form and function. By asking “why?” during the design phase, we delve into the nuances of user interactions, system demands, and future adaptability. It prompts us to forecast potential challenges and ensure that our design not only looks good but also serves its purpose efficiently, both now and in the future.

Scenario: The design team proposes a minimalist UI for an e-commerce platform.

Wondering “why?” helps us understand the rationale: Is it to improve loading times? Or to offer users a distraction-free shopping experience? Recognizing these reasons ensures the design aligns with user expectations and business goals.

6. Thoughtful Refactoring

Refactoring can be a delicate operation. Before tweaking or overhauling a piece of code, understanding “why it was initially done that way?” grants us a broader perspective. By appreciating the original context and intent, we can ensure that our changes improve the codebase without unintentionally introducing new issues or overlooking its original strengths.

Scenario: A developer stumbles upon older, seemingly convoluted code in the system.

Before revamping it, asking “why was it structured this way?” might uncover reasons tied to past limitations or specific requirements, ensuring the refactoring respects the original challenges faced.

7. Unraveling Bugs

Fixing a bug isn’t merely about patching it up. The power of “why?” pushes us to trace its origin. Was it a code oversight? A design flaw? By getting to the root, we ensure stronger fixes and preemptively address other potential areas of concern, ultimately fortifying our software against similar issues.

Scenario: Users report data loss when switching between app sections.

Rather than just spotting the issue, pondering “why does this data loss happen?” helps trace the root, maybe a flawed data-saving mechanism or a synchronization problem, leading to more robust fixes.

8. Staying Curious and Updated

The technological landscape is ever-shifting. However, by perpetually asking “why?”, we keep our curiosity alive. It encourages us to challenge familiar tools and methods, to venture into new territories, and to continuously adapt and grow, ensuring we remain at the cutting edge of innovation.

Scenario: A team has been using the same database system for years.

By challenging this norm with “why haven’t we explored newer systems?”, the team might discover better, more efficient technologies, keeping them ahead in the innovation game.

9. Challenging the Status Quo

Traditions can sometimes hamper progress. By regularly questioning “why do we do it this way?”, we allow ourselves to challenge established norms. This critical reflection often leads to process optimizations, innovative solutions, and a fresh, dynamic approach to challenges.

Scenario: Monthly releases have been the tradition for a software company.

Questioning “why do we release this way?” might lead to the exploration of more agile, frequent release cycles, optimizing both development pace and user feedback loops.

10. Building Stronger Teams

Clear communication is pivotal for team success. The practice of asking “why?” bridges any knowledge gaps, clears misconceptions, and fosters mutual understanding. It creates an environment where ideas are shared openly, collaboration is smooth, and every team member feels valued and informed.

Conclusion

In the intricate tapestry of software engineering, the simple question of “why?” threads its way through, providing clarity and direction. It’s more than just a question; it’s a mindset that elevates our processes, solutions, and collaborations. Embrace it, and watch the transformative magic unfold.

--

--

Joseph James (JJ)
Joseph James (JJ)

No responses yet