Believe it nor not, one of the main reasons why software exists is to help companies to make money. These companies earn money because they have a business. Usually they sell something to customers, in order to solve a problem for them.
A software developer that doesn’t care about the business is missing an important point. It creates a mismatch between the business and the software. This mismatch makes the system harder to maintain, because even if we don’t want it, we’re all domain driven.
The burden to maintain this system lies on the IT team. In other words, denying the domain aspects of the software is a way to shoot yourself in the foot.
How to recognize this mismatch
When this mismatch happens, there are many patterns that emerge.
One of them is the “business sucks” syndrome. You can recognize it when the IT team is always complaining with arguments like “they don’t know what they want!”, or “they always change their mind”, and even “they sell something that doesn’t exist!”.
Of course they sell something that doesn’t exist, otherwise how would you know what to build?
Of course they change their mind, because they are constantly testing and adapting to customers.
Of course they don’t know what they want, precisely because it doesn’t exist yet, and it’s not trivial to know what’s possible to do with software.
Let me raise a warning though, selling something that doesn’t exist is totally legitimate from a business perspective. But stressing someone else because a business man took unrealistic commitment with a customer is not.
It’s the business job to sell stuff that doesn’t exist, and then to handle customers expectations until it’s delivered. It shows why it’s a team work. Without the production team, the business man has only dreams to sell. Without a business man, a production team has no one to sell the product. The sweet spot is to sell something that doesn’t exist, but that can be done quickly. In other words, something that “almost exist”.
How to handle this mismatch
The solution is to let the business drive your software. To let your domain drive your design. Good news, there is a bunch of literature about Domain Driven Design!
It can be resumed by: organize your code, then your teams, then your company around the business, and you will improve software maintainability and customer satisfaction.
It seems trivial, but it isn’t. Trying to know at every line of code which business purpose it serves is hard. Trying to know at every meeting which business purpose it serves is hard. Trying to know if the company has a structure that serves the business is hard.
It’s even harder because as the business evolve, the whole structure (company, teams, software) should evolve as well.
To be fair it’s so hard that I don’t think any company can achieve it. But trying to constantly improve following the principles of Domain Driven Design is good enough to be far better than the average.