Every application involves managing a complexity budget. A complexity budget can be defined as:
An explicit or implicit allocation of complexity across the entire application
"Complexity" here is defined subjectively (rather than formally) and in Stewartian Terms: "I know it when I see it." Or, more specifically to software development, "I know it when I feel it."
One of the primary jobs of an application architect is to manage a complexity budget:
Note that attempting to address complexity can, in fact, add more complexity. A good example of this, from experience is OSGi, which when applied to an application I was working on, made things far more complex, grinding development to a halt. (This is not to say OSGi is universally bad, just that in this case, rather than boosting developer productivity, it effectively ended it.)
A good software architect is someone who manages their software budget effectively, either explicitly or implicitly
I assert, without evidence, that Stewartian Application Complexity grows roughly geometrically with the size of an application. By proper factoring by experienced developers, this curve can be held down for quite some time, and this is one major reason why many good developers are so much more productive than others.
However, this doesn't change the fact that, somewhere out there, there is a Complexity Wall lurking and, if you aren't careful you will run into it and grind development to a halt. I have had multiple experiences with this: one day, inexplicably, development on a system that I was working on went from feeling "large, but managable" to "this is impossible to deal with".
Here are some tools for managing your complexity budget:
Unfortunately, experience shows that managing Stewartian Complexity is a subjective endeavor, and many talented and experience developers will disagree on the proper course of action at a given decision point.
None the less, by making the concept of a complexity budget explicit, these conversations can be more productive and ultimately lead to better software outcomes.
All mature applications are complex.
Finding a new codebase "complex" is not an excuse for tearing everything apart or aggressive refactoring. We must always bear in mind Chesterton's Fence.
If an application is functioning well (or even reasonably) then we should assume that the complexity budget was well (or reasonably) managed. And we must also bear in mind that, with unfortunate frequency, attempts at addressing complexity in existing, large applications often fail or, sadly, make things worse.