Why?

Making Better Decisions by Asking "Why?"

Welcome!

Hi this is John with this week’s Developing Skills - Skills for Developers looking to develop their careers.

🙏 Thank you for being one of the 12,017 software developers who have subscribed, I’m honoured to have you as a reader. 🎉

If there is a topic you’d like to see covered, please let me know by replying to this email📧

I’m launching a podcast for software engineers! 🎙️

It’s called Coding Chats and it’s going to focus on software engineering for the 99%.

I explain what it is in the trailer on the Coding Chats YouTube channel.

Tip of The Week: Make Better Decisions by Asking Why?

It’s a mere three letters, but this tiny word packs a big punch when it comes to making better decisions.

The “five why’s” is a well known technique for Root Cause Analysis (RCA). It‘s a structured approach to determining the root cause of a failure. Here’s an example scenario where a deployment has failed, and RCA is done with the five whys:

1. Why did the deployment fail?

   • Because the application crashed after deployment.

2. Why did the application crash?

   • Because a critical dependency was missing.

3. Why was the dependency missing?

   • Because it was not included in the deployment package.

4. Why was the dependency omitted from the package?

   • Because the developer responsible for packaging forgot to update the configuration.

5. Why did the developer forget to update the configuration?

   • Because there was no automated process in place to ensure all dependencies were included.

It’s a contrived, brief example to show how asking the five whys reveals multiple layers to the issue:

1. The surface symptom: The deployment failure.

2. First why: Application crash.

3. Second why: Missing dependency.

4. Third why: Omission from deployment package.

5. Fourth why: Lack of developer oversight.

6. Fifth why: Absence of automated process.

By addressing the root cause identified by the fifth "why", the development team can prevent the issue in future deployments.

We can also apply the same technique to making better decisions. Instead of solving the first problem we’re faced with, we can dig into the issue using the five whys and discover more detail allowing us to offer a better and perhaps different solution.

Here’s an example.

Imagine our software development team is debating whether to adopt a new technology stack for an upcoming project. We decide to employ the five whys technique to delve deeper into the decision-making process, here’s a simple example.

Problem: Uncertainty over technology stack selection.

1. Why are we uncertain about the technology stack?

   • Because we're unsure if the new technology will adequately meet the project requirements.

2. Why are we unsure about meeting the project requirements?

   • Because we lack experience with the new technology and are unsure of its capabilities.

3. Why do we lack experience with the new technology?

   • Because we haven't invested time in conducting thorough research and testing.

4. Why haven't we invested time in research and testing?

   • Because we've been focused on meeting tight deadlines and haven't allocated resources for exploration.

5. Why haven't we allocated resources for exploration?

   • Because there's a perception that sticking with familiar technologies will expedite development and reduce risks.

Upon reaching the fifth "why," we uncover a crucial insight: the perception of risk reduction through familiarity may be limiting our ability to explore other technologies.

One possible solution we might then consider is reevaluating our technology selection process by:

• Allocate dedicated time and resources for researching and testing new technologies, including the proposed stack.

• Encouraging collaboration and knowledge sharing among team members to mitigate the fear of unfamiliar technologies.

• Prioritise long-term benefits and project scalability over short-term familiarity when making technology decisions.

By addressing the root issue we have identified through the five whys analysis, we can make a more informed decision regarding the technology stack.

Two Ways I Can Help You Level Up As A Software Engineer:

1. I write another newsletter, Coding Challenges that helps you become a better software engineer through coding challenges that build real applications.

2. I have some courses available:

   1. Building Your Own Redis Server (Python Edition) which guides you through solving the Redis Coding Challenge in Python.

   2. Build Your Own Shell (Go Edition) which guides you through solving the Shell Coding Challenge in Go.