As you probably know, I specialise in DSLs, modeling, code generation and interpreters and such, plus the architecture of software systems that rely on all of these at their core. While none of this stuff is the proverbial rocket science, it is technically not trivial with all the metalevels and type systems. It is also a bit off the mainstream of software development, and it is therefore not buzzword-compatible.
At the same time, the approach can be extremely beneficial if the domain is a good fit. It can also have significant (positive) consequences for the processes and structures in an organisation, and ultimately, the business as a whole.
As a consequence, am I often asked to explain and justify the approach, not just to technical people, but also to architects, product owners and management. Because the approach isn't mainstream, management wants to have a say in the decision of whether to use the approach or not. And here is where I frequently run into the following problem (and for the sake of the argument here, let's assume that using a DSL and the associated software architecture really is the best solution to the problem at hand.)
The higher up in management my interlocutors are, the less technical background they have. In addition, the higher-up somebody is located in the leadership hierarchies, the less time they have available for this topic. Both constraints are understandable, but quite unfortunate. The situation leads to two options of how to proceed:
I can try to seriously explain the benefits and drawbacks of the approach. This requires some degree of technicality. This, however, doesn't work if people don't take some time and energy to dig in.
The other alternative is to rely on the usual "management-compatible" terminology, using words like "faster, cheaper, better". I can follow the general advise of adapting my arguments to their background, focusing on the big picture, emphasise the benefits and connecting to strategic goals. This, however, is what everybody else also does relative to "their" favourite approach -- nobody will advocate for an approach that does not promise these benefits. So at this level, all technical alternatives are essentially indistinguishable. So the decision is made based on how well somebody can tell the story and not based on the technical merit of the approach.
And here's the thing: if management is familiar with anything technical, it is of course the mainstream approaches or whatever is currently hyped. So it is very hard for non-mainstream approaches to win this competition.
Sometimes the supposed remedy is to create a systematic comparison table: "Please compare the DSL approach to XML, Json and DDD". Of course this doesn't really make sense, because it's not clear what the corresponding XML or Json approach is. I can serialise my models as XML, so the two are compatible? DDD and DSLs are quite compatible. But people are so far removed, that even the supposedly objective comparison table can't be meaningfully discussed.
Another option is to create a prototype. A good idea in general. But of course it's usually infeasible to build two or three different prototypes so they can be compared, nobody wants to spend the effort. And for approaches that have medium- to long-term benefits, a prototype doesn't show much anyway.
By the way: the problem is not that I would be unable or unwilling to take the time to explain potentially complex topics to people without the specific technical background; I've been doing this for years as part of my podcast. The problem is that I don't get the opportunity to do that because people have no interest or no time.
So should I just bullshit my way through the situation? Create the fanciest Powerpoints so my position will win because it has the best "marketing"? Nothing against creating good slides, but this is not the way I want to work.
Unfortunately, this article does not have happy end. I really don't know what to do here. Your input would be appreciated!