How often did you talk to the client, and you got the feeling you don’t understand each other at all? If more than a few, then you will definitely understand my story.
Programming projects are designed to reflect how a given part of reality works in some approximate way. Often these are production processes used in a given company. However, mapping is not an easy task for the development team. This may be due to a lack of experience in a particular industry.
When working on a project for a logistics company, it isn’t easy to expect that the team will understand all the processes that occur in such a company. For example, the loading and unloading of goods may require the preparation of special waybills. Seemingly simple, but without information from the client, it is difficult to think about it right away.
Understand the domain of your project
In the beginning, the project was an ordinary logistics project for me. What can go wrong? I did not understand what the main business assumptions were. I knew these assumptions and the requirements for specialized documents and their number, but I did not understand why they were used. It was difficult for our solution to be translated into the client’s language as a team.
Understanding the problem domain came to the rescue. After defining a coherent language with the client and understanding the rules governing his world, better programming solutions could be provided.
Don’t try to be an expert (right away)
Team members often have the illusion that they understand the industry perfectly well. They want to show themselves as experts, even though they are not. However, try to understand the domain, be bold enough to ask if something is not clear to you. The clients do not perceive it as a lack of commitment or ignorance. For them, it is often an excellent investment because instead of presuming and creating a poor-quality solution, it can immediately explain the meaning.
Your knowledge will grow over time. You will begin to understand the business assumptions, and it will be easier for you to make changes. You will become a domain expert who knows and understands the principles of operation and the most important concepts used by the client and users.
Help your client
Business often has the impression that it knows how and what to prepare. Unfortunately, they cannot translate it into code. Thanks to the common language, it is easier to achieve assumptions.
A common language is an opportunity for discussion with the client. This allows not only to translate the requirements into code but also to think in the context of the product. It is also a great way to eliminate errors. Fewer things seem unclear, making it easier to spot inaccuracies, errors, and contradictions. A reasonable client (this is the one we want to work with) will appreciate your efforts and commitment.
Knowing the domain of the problem makes your work easier
Knowing the subject of the project, it is easier to introduce changes because we know (probably) what the consequences of our changes are. Thanks to this, we eliminate the problem with code refactoring and its enormous complexity.
It is also a way of fruitful cooperation with the client. We can eliminate situations in which the client makes a decision, and all we have to do is introduce it. Fewer times, we are only the contractor, and more we influence the project.
There are also no bottlenecks while waiting for the domain expert’s decisions. We understand the expectations data faster. Also, we can prepare a better code, both technically and in terms of products. It can be a way to eliminate shifting tasks between people or perform tasks that don’t make sense.
In communication, make sure you use business terms that everyone understands in the same way. If something is named differently, it is worth making it more consistent. This common language should also be reflected in your software. If you have a seller’s context, don’t use the term user because that’s how you store it in the database.
First of all: understand
Understanding the business is critical. It allows you to achieve better results in a shorter time. Without a common language and understanding of the project domain, it’s hard to expect everything to be perfect.
If something goes wrong, it will be easier to save the project. Otherwise, we can go down with the ship at an express pace.