This only has an impact when we want to change a system. Coincidentally, the majority of our work is changing a system through addition of new functionality or

This only has an impact when we want to change a system. Coincidentally, the majority of our work is changing a system through addition of new functionality or maintenance. I've thought about this problem for a long time. The conclusion I've come to is that it happens because the code doesn't look like the domain. Domain language is often missing in the code the engineers are working with so when new changes are requested the engineer needs to translate between the domain language and the language the code is using. I work in an object oriented language so my perspective is as follows: Ideally, all that should be required is a correct domain understanding. If the objects in the code reflect the domain as understood and explained by the people giving the requirements then the engineer's job becomes easier. Instead of solving 2 problems, translation and engineering, they only need to focus on engineering. For example, imagine a payment system. A requirement comes in stating that the way a credit transaction in a payment is processed has changed. The transaction should now be processed by doing x, y, and z instead of a, b, and c. The engineer should be able to find an object in the code called a payment that has a credit transaction object with a method named process. Once they find this with a simple text search they know exactly where their change needs to happen. They should then see a, b, and c happening as explained in the domain language. Once this is identified the change can be performed. In reality, we seldom find domain objects with domain behavior in our code. What we find are Processor and Controller and Handler classes that have nothing to do with the domain. The behavior or data that we need to change is spread among multiple of these classes whose connection was arbitrarily decided by another engineer at a previous point. The new engineer has to work twice as hard to understand what decisions the previous engineer made to represent the domain. It's much easier at first to do this translation work because we don't want to, or have time to, understand the domain. But business domain experts are experts for a reason. They know how to solve business problems within their domain. We are not domain experts. So we end up reinventing the domain solution wheel when we do things this way. We end up solving the business problems and the engineering problems. Instead, we should see ourselves as modelers. Remember that computer science arose as a sub field of physics. The main purpose of physics is to develop models that represent the real world and solve problems using those models. Our job as software engineers is to model the domain and solve problems using those models. Our job is not to translate requirements into technical solutions. Nor is it to solve business problems.