We understand each other.
Try describing the business logic in your current system to a nonprogrammer domain expert. Are you able to explain how the system works in terms the domain expert understands? Can you avoid programmer jargon, such as the names of design patterns or coding styles? Is your domain expert able to identify potential problems in your business logic?
If not, you need a ubiquitous language.
One of the challenges of professional software development is that programmers aren’t necessarily experts in the areas for which they write software. For example, I’ve helped write software that controls factory robots, directs complex financial transactions, and analyzes data from scientific instruments. When I started on these projects, I knew nothing about those things.
It’s a conundrum. The people who are experts in the problem domain—the domain experts—are rarely qualified to write software. The people who are qualified to write software—the programmers—don’t always understand the problem domain.
Hiring programmers with expertise in a particular domain will reduce this problem, but it won’t eliminate it. In addition, given the choice between a great programmer with no domain experience and a poor programmer with lots of domain experience, I would choose the better programmer.
Overcoming this challenge is, fundamentally, an issue of communication. Domain experts communicate their expertise to programmers, who ...