Understanding the domain

In software engineering understanding the domain is key to providing business value.

“The design of good houses requires an understanding of both the construction materials & the behavior of real humans” — Peter Morville

To develop good, comprehensive software we, as software developers, need not only to understand the technology and architecture behind a given solution.
But we need to understand the business domain including the customers needs.
Many great projects have been discarded because of poor domain knowledge even though the solution is a shining master piece with all the bells and whistles.
A correction; the solution is not a master piece until it can support the customers business.

The business domain is of highest importance when developing a software solution.
Customers will often happily purchase minimum viable products, if it support their business needs.
I.e. if it do not it is of no value to them, even with all the bells and whistles.
Providing business value to the customer is a tough nut to crack and it can never be considered trivial.

“Customer collaboration over contract negotiation” – Agile Manifesto 2001 Kent Beck et. al.
The manifesto describes how it is important to understand the customer which we are creating software for, and that is not done by writing comprehensive contracts.
Software is one of the business areas where everybody on the team needs an understanding the domain, it is hard to define everything beforehand and therefore, we use techniques which let us do a little at a time to comprehend what we are building.
It requires understanding of the materials used and behavior of real humans!

Does the customer know it all?
Certainly not, when having a successful product the strategy changes and it can be good not to listening to customers and instead focus on disruptive innovation to stay competitive in the market.
However, this will be left for another blog post.