Most tech people I know agree that solutionizing is a bad thing. This is when the non-technical “customer” (a project manager, a product owner) tries to specify the technical solution for the development team. They may sketch out the architecture, specify how files need to be parsed, or (in extreme cases) detail extensions to the database schema.

There’s one commonly-agreed reason why this is bad: it disenfranchises the development team. They don’t get to make their own decisions, and therefore they are prevented from taking responsibility for the system. Consequently, we also miss the chance of innovation and more intelligent (better) solutions to the given problems. Ultimately we completely undermine the reason we hired intelligent people in the first place, because we deny them the chance to use and exercise their intelligence.

That disenfranchisement is a problem about the future—it’s a problem with how things will be as a consequence of solutionizing.

But solutionizing also highlights a problem with the past, and that is this: the very fact that someone outside the development team can detail a low-level solution suggests that the system is not sufficiently abstracted to address high-level problems. To put it another way: if the system was well-designed, and its way of working aligned well with the business problems being faced, then there would be no need for a business-oriented representative to address lower-level issues.

This is a major goal of domain driven design (DDD), which provides a way of designing software such that it precisely matches the expression of the business problem. And having worked with DDD I can say it is successful there. But we don’t need to use DDD to design software well. If the system is logical to the end user, if intuitively-simple business problems have simple consequences in the system, if complexities and quirks in the software exist only because they reflect complexities and quirks of the business processes, and if the language of the system matches the language of the business domain, then any requirements from the end user (the “customer”) should be able to be expressed exclusively in high level language.

Solutionizing leads to problems in the future. But it is also a sign that things have gone awry in the past.