How do you reason about how complicated software is?
We all strive to build maintainable and, hopefully, simple, yet powerful systems. And in our own ways, probably all the things that we help to create fulfilling our very own definition of that. I don't think there's a lot of folks who would build complicated stuff just for the sake of it - yet the amount of overly complicated solution out there is just staggering. And there's a bunch of really good reasons for why that happens - the most important probably being the 4th dimension, i.e. the effect of incremental change over time on any given design.
Even if you start with something simple, without proper stewardship, direction and someone saying no to wild ideas, even the best systems tend to invite technical debt, and that regularly manifests itself in a thing being more complicated than it should be.
And I'm going to pause here for a second. We need to clarify two terms before rolling on. The first term is that of complexity. It very closely means that a system with more components and interactions between those components is likely more complex than one with fewer components - it speaks to the intrinsic properties of a system or a problem. Complicated means extraneous elements that make dealing with something more difficult, without necessarily adding value.
Playing three games of chess at the same time might be complex, doing it while blindfolded is making it complicated.
One of the very first things I do when trying to understand really any system I'm dealing with is: How complicated is it? For that, I usually need to first understand the business domain, the building blocks and their connections. Once you understand the rough problem, it's all about determining what the delta between the necessary and the existing solution is. The bigger that difference, the more complicated your solution. There is no real world system where that difference is zero - at least I've never seen it.
But how do you actually quantify how complicated a system is, aside from judging it from an experience point of view and applying some gut measure metrics? I find that to be a really hard problem, as you're looking at plenty of different technologies at different flight levels at the same time - you're looking at code just as much as you're looking into a deployment model. You need to understand that having 3 services written in the same language, deployed using the same technologies is vastly different from having 3 services that are deployed in 3 entirely different ways. In my world, that is.
Coming back to my calculation model, the unfair bias here is that any delta between an ideal solution and the solution at hand is based on a ideal solution that is solely based on my preferences, experiences and my lack of information on what informed some of the decisions of the real system. So it's never an objective measure for how complicated is, it's only a proxy, and effectively only measures how complicated I think a system is.
The one way that I've been thinking about for a while is a point model, where each element in a system gets a number of points. Each service gets a point (or two or three, depending on how heavy it is), every connection between two services and so on. While this would certainly not be a perfect metric, it would help to gain an understanding, something quantifiable, on how complex a system is, to begin with. And that might help to understand how complicated something is - even though that's always subjective, isn't it.