Asymptotic software

Based on my observation and experience, software complexity is like a numerical series. As a piece of software evolves, its complexity can follow two paths:

This view is in opposition the generally (if tacitly) held view that software complexity is roughly linear with respect to the amount of features it provides.
Given the conceptual and technological tools at our disposal, the most likely outcome for a piece of software is to grow in complexity, often at an accelerated rate. If this luck befalls a piece of software, after a few short years it will be either scrapped or treated as legacy software; legacy software is a piece of code that is both critical and that nobody wants to fix or work on.
I believe however that a piece of software can be designed to approach a certain level of complexity, and stay there forever. My favorite piece of software, Redis, seems to follow this course. As time goes by, the software becomes more resilient and also grows in features, but its overall complexity is very similar to what it was months or years ago.
I like to call this kind of software asymptotic software, because its complexity is bounded. I strive to make all my code asymptotic. Here’s a few ways in which I work towards this end:

I strive to create code that will last and will be useful years, if not decades from now. Even if the technologies last years, the patterns will last decades. And if the solution has something approaching beauty, then code is not just a means to an end, but a way to express deep feeling and appreciate our existence.