[imiric]

> Complexity is fairly straight forward in my opinion.

That's a bold take.

The difficult thing with complexity is that it's an abstract and, sometimes, subjective concept. (Not speaking of measurable complexity like cyclomatic or algorithmic.)

It may involve abstractions, yes, but those are usually introduced with the argument that they—ironically enough—_simplify_ some interface or process. It's difficult to argue against that since we deal with abstractions on a daily basis which _do_ make our lives easier, from the hardware layer and up. So then the task of removing abstractions becomes an uphill battle to convince the rest of the team that this is indeed a good idea. This is a sociocultural and political problem, not strictly related to engineering.

So I don't see the task of resolving complexity as being this straightforward. The best approach I've found of dealing with this is to focus on things we can measure instead. Use linters to warn you about cyclomatic complexity, function length, dead code, single interface implementations, and any other quantifiable metric that contributes to increasing complexity. Even this is often difficult to align on within teams, but with it in place at least there's an objective metric that can guide the team in the right direction.