Jared Diamond's Collapse explores this, both in positive aspects (Japan and several successful adaptations in Pacific Island and Borneo populations), as well as negative ones (Greenlander's insistence on raising cattle and not adopting Inuit practices).
(not an affiliate link)
Also, the idea of "diminishing marginal returns on added complexity" suggests a lot about why maintenance, extension, and management of software systems becomes harder over time.
You'll find that Diamond cites Tainter and draws much from his model of collapse.
The funny thing is that I'd started evolving a theory of systems complexity before running across Tainter. It runs basically like this:
⚫ Proof of concept. Works for the creator.
⚫ Refinement: Incremental improvement of concept in function, reliability, efficiency, and utility.
⚫ Embellishment: Layering complexity on top of an initial design. Though initially well intentioned, the end result is fragility, impediments to usability, and eventually, rot. A baroque era.
⚫ Recaptitulation or replacement: An overly complex design may find itself refined back to a more functional one (e.g.: the car tailfin era recaptitulated into today's econo-box and performance sedan market, though SUVs perpetuate the meme of ostentatious nonfunctional embellishment). Or it may find itself replaced entirely by a more appropriate technology, as may be happening now with PCs being supplanted by tablets and mobile devices offering much of the functionality required by users.
Posted to G+ here (and yes, that's before I encountered Tainter). The idea had actually been percolating for at least a year prior.
It's not specific to any particular technology, and I've seen examplars across a wide range of cases: software (utilities, GUI apps, Web design, OSes), cars, audio equipment, aircraft, architecture, etc.
I think that what Tainter has to say corresponds strongly with this, though his point is also that complexity is undertaken, when it is, because it adds value and/or capability.
He also notes that complexity generally isn't undertaken for its own sake -- that there's a resistance to it.
Another correspondence with this is noting that a great many technical tools (high level programming languages, IDEs, revision control systems, etc.) are all effectively means for coping with complexity and that in the IT world, people are constantly working at the complexity frontier -- the reason software still has bugs isn't because we're not getting better at it (though sometimes I wonder) but because when we do get better, we make ever more capable -- and complicated -- systems. With more failure modes and hence bugs.