Introduction

I recently started a book called "Hands-On Domain-Driven Design with .NET Core" by Alexey Zimarev. The book so far has been very interesting and allowed me to think about my past and current experience delivering software as a part of a team. This article is to put some of those thoughts down in hopes that others find it useful.

Problem Space vs. Solution Space

When delivering software, the first step is usually understand what it is we need to deliver. In my experience, this is completed with a product owner / project manager, developers, QA, and sometimes someone who will write the documentation for the new functionality. The book describes the idea of creating the requirements for the feature in 2 different "spaces", the problem space and the solution space.

Problem Space
The problem space is around the actual problems that the software is attempting to solve from the end user perspective. This manifests in the many organizations as Gerkin syntax written for the user story.

Given I want to look at my bank account
And I enter my username and password on the screen
And I click the Login button
Then I expect to see my account information on the following screen

Solution Space
The solution space is around how the team will implement the feature. Here, the team thinks of possible situations that can occur in the implementation of the feature.

When gathering initial requirements and writing the user stories for the feature implementation, staying in the problem space is extremely important. As a team, we need to try to deliver software that not only solves the user's problem, but also delivers value add to the user. Writing requirements while thinking about the solution space, especially in the beginning stages, can cause missed deadlines by spending too much time on requirements that does not give the user value add.

As developers, we usually want to jump right to the solution space when gathering requirements. This can create complexity because we create requirements on how we will solve the problem, and not necessarily what the problem is. This can lead to creating complexity.

Categorizing Complexity

The book talks about 5 types of complexity when implementing solutions.

Simple
This type of complexity, as you may have guessed it, tackles the simplest of problems. Here, we have known knowns, meaning that we know the problems we will face during implementation. This type of complexity usually does not require event storming, which is a DDD topic that we will delve into on a subsequent article.

Complicated
This type of complexity suggests that the problem the team is trying to solve has known unknowns. We know there are some domain details that we do not understand deeply and we know we will need to engage with stakeholders in order to deliver our software.

Complex
Here, we have unknown unknowns. The team is unfamiliar with the domain we are trying to solve a problem for. It is important here that the team engages with stakeholders before starting the implementation. This is a great situation to use event storming.

Chaotic
As the author of the book puts it, "hellfire burns and the Earth spins faster than it should". This is usually the prototype stage where the team (or a few members of a team) quickly puts something together to analyze and see if it will provide value to a user.

Disorder
This is the abyss. Here, the team has no idea on how to even start to deliver software. The only way to escape this type of complexity is by breaking the problems down into smaller problems.

When a team is in the initial phase of the process, it is helpful to categorize the problem/s into one of these categories. However, we must be careful not to be too hasty. Issues occur when we let our biases drive the categorization of complexity

Bias

The book describes two systems our brain uses for decision making. System 1 are autonomous or unconscious decisions. We don't really decide to breath, we do it because we have been doing it since we were born. Here, we don't engage in the part of our brain that analyzes what problem we are trying to solve.

System 2 is more analytical. We probe into the problem and think of different scenarios that must occur to resolve it. This is a slower but more thorough form of decision making.

When creating our requirements, we need to decide how to categorize the complexity of the work we will need to complete. During this process, we need to make sure we are using system 2 thinking and do not let system 1 take over, based on our biases. Below are types of biases mentioned in the book:

Choice-supported bias
This is when we make decisions because I suggested the solution to the problem. I don't really listen to others on the team because my solution is clearly the best. This can often occur when we write requirements based on the solution space. There is a problem here because if I am the only one making the decision, it is easy to mis-categorize the problem because I think the solution is simple to implement where as maybe it complex because I don't know what I don't know.

Confirmation bias
This often occurs because we used choice-supported bias in a previous decision. Here, I dig in to my previous decision because I made the right decision.

Band-wagon effect
We have all been on that team where one member is the most vocal and everyone just goes with what s/he suggests. Sometimes this occurs because s/he was successful before or sometimes it occurs because s/he talks so much that no one else can get a word in. As a team, we should make sure we engage in system 2 thinking to discuss and/or challenge decisions being made.

Overconfidence
This can occur because we have previously encountered the problem before in a different domain. "We have implemented single sign on 3 times already, so this will be a piece of cake". This can lead to incorrect categorization because we don't try to solve the problem within the domain that we are currently in.

Availability Heuristic
Here, the team makes the decision because we believe we have all relevant data needed to implement the feature. We may not thoroughly engage the stakeholders on what they need. This is a problem that event storming hopes to solve.

Conclusion

I hope you found this article useful and helpful when your team are gathering requirements for delivering software. I have already learned of techniques to use on my current team and will be writing more articles as I progress through the book.