Changing the way we look at building software can have a huge positive impact on the outcomes, Products or projects that can't abstract their entities and models to objects and interactions will fail to build knowledge. Eric Evans describe this in his book Domain Driven Design.

To communicate effectively, the code must be based on the same language used to write the requirement, the same language that the developers speak with each other and with domain experts.

In the old waterfall model of building software, analysts and experts are responsible for providing the necessary details of the business workflow. The Technical team meets with the experts (accountants, sales, distribution ..) to describe the desired outcomes and then they go build it, ship the feature and iteratively ask for what is next. The experts here have the full responsibility for describing the business models, without interaction with the technical team to learn from each other and design an abstraction of the business workflow. A programmer will be doing a good job if he can manage technical complexity well (Testing, refactoring, design patterns, devops ..), but what about abstracting and designing the business logic ?

Conway's law

Organizations design systems that mirror their own communication structure

If knowledge exchange between business and the technical team is shallow, the produced software will only do basic things (ex: CRUD) and fail to develop ideas and deep connection with the business. How the business will be growing? what are the different ideas the product can explore? how to design a unique product that will last and scale for the next years? how it will handle the business evolution and provide feature with competitive advantage? how the Product will be customer centric?

A great Product is an abstraction of rich models through clear sentences, diagrams and objects that aren't just data schema with fields and actions, but vivid and integral to solving a complex problem in a way everyone can understand and develop further. The models and objects are never perfects but they evolve, and this become a continuous flow of knowledge between domain and technical experts.

A great team aims to improve the technical knowledge with continuous learning but also learn about the domain by asking relevant questions. We are solving business problems, the business model complexity should be at the core of the product models designs.

A developer is not asked to became an accountant when designing an ERP, but he will get the relevant knowledge base and learn the major concepts related to the Product. Domain experts are not aware of the complexity of their mental maps, through discussions and designs abstractions, feature and objects backlog are clarified, designed, prioritized or placed out of scope.