Chapter 2. Finding the Core Problem

Every piece of software is written to solve a problem, and in turn is a perfectly valid solution for this exact problem. Sadly, the problem a piece of software solves so perfectly is not always the problem the software was created for in the first place or even the problem the programmer had in mind when the software was written. The history of programming is full of examples where developers tried various ways to come up with a way to be able to perfectly state a problem first, and then implement a solution. Developing software based on the waterfall model is a great example of having a nice idea that failed to deliver on the promise. When you ask the parties involved about the failure, the reason will most likely be that the problem diverged from the specification, or the specification was misunderstood in—according to one party—a very obvious way. So, why is this?

When starting a software project, especially one motivated by a business need, we set out to model a part of the real world and apply a set of constraints and algorithms to it, to ease the job of one or more parties involved in the business. The problem is that the party that has the issue the developer is trying to solve is most likely not the developer. This means that the developer first has to get an understanding of what the request really is to actually know what is supposed to be developed.

How can we get a deep enough understanding of a certain part of the business without the (most likely) years of experience our clients have ahead of us? The solution to this, and the most likely problem, is communication. We need to find a way to explore the problem deeply enough, and backed with our knowledge of how to model a world in software, to be able to ask the right questions. We need to do this in such a way we don't lose the non-technical people so that we can draw from their understanding. This comes back to the language mismatch between developers and business people, and it is probably the biggest obstacle to overcome. In domain-driven design, this is referred to as the ubiquitous language of the project, a language shared by all parties involved in the project. Establishing this kind of language allow us to communicated clearly across team boundaries, and as mentioned before, this is one of the core ideas in domain-driven design.

Coming back to our example of the orcs running a dungeon, we don't know how this is done; we don't even completely understand the constraints that cultural aspects involve or apply. The world of the orcs is one in which we are an outsider who can only watch, ask questions, and model it according to our understanding. We naturally have to trust the local experts. Even though we aren't as much of an outsider in real-world problems, we should always try to view the problem from the outside as much as possible because, in a business that has taken years to grow, our own assumptions are probably wrong anyway.

In the following, we are going to explore the problem and introduce a set of tools that will help to do this. We will cover several aspects, but most importantly the following: