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!