Yeah I mean this is great in theory, but in practice it's very very hard.
Suppose I were to ask you to explain to somebody non-technical why your application shouldn't have 12 different databases. It's incredibly easy to provide hand-wavey claims about inefficiency, but non-technical people are rightly skeptical (after all for every good idea there are 10 developers claiming a complete rewrite in XYZ will 2x everything).
How can you really provide hard evidence that an application with 1 database instead of 12 will be easier to develop in? Are you going to have devs write code for both cases, and show how many fewer lines of code it is? Are you going to take a dev survey? You can provide your word that certain production bugs were caused by this, but that's again presuming this individual believes you.
Even if you could really spell it out in detail, it's likely they wouldn't have the patience to listen. A chess grandmaster could probably spend an hour explaining a crucial chess move to me, why couldn't an engineering problem warrant over an hour of explanation?
I find completely irrelevant details (how distressed you are by the problem, your race, your last performance review) often have an outsized bias on how persuaded people are.
I think I mentioned in my post like 3 times that this is a difficult thing to do even for those who are skilled. My point is that you still have to do it if you want a chance to get the outcomes you desire.
// How can you really provide hard evidence that an application with 1 database instead of 12 will be easier to develop in?
Great example. Like I said, the first step is to confirm a shared understanding of the problem. "Easier to develop" is not relevant, but "feature delivery velocity" is. So step 1, I'd ask the people I am trying to persuade whether they perceive a feature delivery velocity issue on your team.
If the answer is no - well that's a whole different conversation.
Assuming the answer is yes, the next question is - would it be impactful to the business if the velocity went up and should we think about how to do that? Again, if the answer is no - that's interesting. Ask why not?
If the answer is yes - then you come back with "as far as I can tell, one of the sources of our low velocity is the complexity. For example, we have 12 databases and on average, every feature requires 6 of them to be changed. From casual observation, each DB takes X days to update so this is how much tax we're paying every feature."
Then you ask - "does this make sense to you? I am not saying this is the only problem but it seems apparent to me as your technology lead that we're paying a high complexity cost for this design. Let me know if you're with me?"
If they say "no" - great - troubleshoot that.
If they say "yes" - "ok great. I have an idea for how we can go down from 12 databases to 3 at a development cost of X. Ballpark we will recoup that cost in Y months. Should we try this?"
In my experience, walking people through it this way patiently (and it may be multiple conversations), I either get a "yes" or learn a good reason why it shouldn't be done, 100% of the time. Notice that in this approach, I neither lead with the answer "12 DBs bad!" nor overload them with technical detail - but I give them just enough to follow my own logic - after all you must have done similar thinking (even if just intuitively) to arrive at your conclusion. Now you're externalizing your intuition in a way that others can follow.
Like I said - very hard to do. Most people don't bother, many other people are horrible at it (but way ahead of those who don't try!) But either way, this is the only way to get shit done so you gotta do it.
Suppose I were to ask you to explain to somebody non-technical why your application shouldn't have 12 different databases. It's incredibly easy to provide hand-wavey claims about inefficiency, but non-technical people are rightly skeptical (after all for every good idea there are 10 developers claiming a complete rewrite in XYZ will 2x everything).
How can you really provide hard evidence that an application with 1 database instead of 12 will be easier to develop in? Are you going to have devs write code for both cases, and show how many fewer lines of code it is? Are you going to take a dev survey? You can provide your word that certain production bugs were caused by this, but that's again presuming this individual believes you.
Even if you could really spell it out in detail, it's likely they wouldn't have the patience to listen. A chess grandmaster could probably spend an hour explaining a crucial chess move to me, why couldn't an engineering problem warrant over an hour of explanation?
I find completely irrelevant details (how distressed you are by the problem, your race, your last performance review) often have an outsized bias on how persuaded people are.