The more complex a system is, the harder it is to maintain. However, the computer you're using right now probably is much more powerful than a computer from the 1960s. It's easier to use a keyboard rather than punchcards or tickertape. The system you're using is a complex system, and much of that complexity is hidden from you.
That's the way it usually works with software. The personal computing device you're using, though, is an evolution of what works and what is sustainable. It has a shelf life too, according to Moore's Law. The cost has decreased over the decades. It's really not a bad model for sustainability in technology.
Software Entropy is almost the reverse of that when it comes to technology. It refers to a tendency of software to become more costly and difficult to maintain (technical debt being a part of that) over time. If you've ever worked or owned a long term software project, you know this is true.
There are two perspectives on the complexity. I'll start with the one that engineers and developers need to communicate to management the most.
Your software is probably trying to do too much for too many. If everyone wanted swiss army knives, there would be no market for corkscrews. Software as a service (SaaS) and Software as a product constantly have this difficulty. The key issue is trying to please everyone. You can't. Stop it.
When customers are using your product in ways that it is not designed for, you don't have to modify that product. You can... create a new product for them (if it's worth it). Sure, you can use existing software to build upon - ask the (hopefully) smart people you hired - or maybe it's an opportunity to get rid of some of the technical debt and do something new that will help existing projects. Investing a lot or a little is not the key. The key is to invest wisely.
Spinning off new products sounds like an administrative nightmare, but it isn't necessarily so - particulary if the changes are based on the same code. Good object oriented practices, coupled with good software engineering and good architecture, will allow for reduction of complexity and technical debt over time.
An anecdote. Almost 2 decades ago, we got a new Director at the Sensor and Guidance Products at Honeywell, Inc. - Ben Simmons. At the time, we had an issue with engineering departments overflowing with work because our salespeople were very effective. Ben, in a meeting with the sales team, said: "We're getting 100% of the business we bid on." Cheers. He continued, "...and that means we're not bidding high enough."
Development and Maintenance Complexity
For software engineers and software developers, this is the obvious complexity. The more complex a project is, the more complex it is to maintain or add new features to. It can be argued that proper practices can avoid such complexity, but it's a poor argument. All best practices and good development do is mitigate complexity.
How many times have we heard, "We need this new feature!", or, "We have to fix this bug!"? All too often it's thought to be a 'simple thing to add' or 'a simple fix' when it's complicated by a culture of technical debt that hasn't permitted the refactoring of code and architecture to make the fixes simpler (or not necessary at all). In a world where businesses expect continuous change, they need to understand that there is a need for continuous delivery approaches that require investment in both time and finance to get started: the foundation for the continuous delivery must be set.
And the foundation moves.