It doesn’t matter what piece of software you’re building, the key to success lies in having a deep understanding of the problem you are aiming to solve. It’s so common to for a project to get well underway before the problem domain is fully understood. It’s a natural thing to happen.
When a client comes to you with an idea for software, we usually begin by talking about their idea in terms of our technical minds. When they’re explaining whatever requirements they’ve put together, our wheels start spinning with how we’re going to architect our solution, or how we’re going to design this feature or that. Before we know it, we fire up our IDE of choice and start hammering out our solution.
Before long, we begin to run into scenarios that we’re not sure of what the right answer is. At this point, we are left with a choice: get the answers to the questions we have to better understand the problem, or make assumptions about what is probably the right answer, and keep being productive. The misunderstanding is that breaking stride to get a better understanding of the problem is not productive. When we do this, we’ve already set ourselves up to fail. It doesn’t necessarily mean you are going to fail, but there will be pain. As we jump to implementation, we are giving up great opportunities to dive deep into the problem domain. By taking the time to dive into the problem domain, not only are we still productive, but we’re actually more productive in the long run as we will inevitably be more accurate in our solution, requiring much less rework.
So how do we dive deep into understanding the problem domain? The short answer is to ask questions. But it’s not just asking questions, it’s asking the right questions.
The end user is your greatest asset. The key to understanding the problem is to understand how the end user works and how the product fits into how they work. Get the end user talking and keep them talking by asking “What else?” and “Tell me more about _____”.
Understand the business domain. Your technical domain should match your user’s business domain. When you begin introducing technical terms to a user’s vocabulary, you are attempting to change the way they work. Instead you should be aiming to avoid technical terms that have no place in the business user’s mind.
Understanding the problem domain is both hardest and most important aspect to developing any piece of software. I like to never assume that I know enough about the business domain to make assumptions about it. It’s always a better use of time to get the answers to questions as they come up than making assumptions and continuing down the wrong path.
