Starting with why

As software developers, we often get caught up in the technical details that we forget to ask one fundamental question. Why?

Following the path of Domain Driven Development (DDD), we can ask some fundamental (sometimes obvious) questions in knowledge crunching sessions so that we may build the right things in the right ways.


Why is why so important when making great software solutions and products? This question fundamentally sets us in the right direction before we go racing off to solutions.

  • It teases out the hidden or obscured requirements in the specifications
  • It creates opportunities for developers to interact with the principal stakeholders
  • It creates a shared understanding of what is possible
  • It identifies the unique selling position of the product


I am reading Patterns, Principles, and Practices of Domain-Driven Design to try to understand how to build great software solutions. I was pleasantly surprised that the first eight chapters focused on why.

Without going into detail of DDD principles and practices, here are a few questions you could ask your team before touching the keyboard to hack out code.

  1. Why are we building the product?
    1. Who are our customers/users?
    2. When do we need to deliver?
    3. What else can we buy off the shelf instead of building?
  2. Why would customers/users choose our product over another?
    1. Who else is providing the same products?
    2. Would it still be relevant when we deliver our product?
    3. What is unique or attractive about our product?
  3. Why have we decided to build it in this way?
    1. Who is involved in the problem-solving process?
    2. How do we know when we are done?
    3. What does good / great look like?

These seem like obvious questions when we ask them out loud. Yet, we often forget to ask or make assumptions that we should not be making.


Since starting with why I have noticed the following benefits.

  • I have more clarity and confidence to make complex technical decisions
  • I find that I can communicate clearly and efficiently with team members because we share the same context
  • I am under less pressure to deliver because my objectives are clearer and more realistic
  • I spend less time trying to perfect all my code because I know which parts are important and those that could be replaced


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s