Once upon a time, I wrote simple client server applications in Visual Basic (VB3!) with an Oracle database back-end. My government client, who dictated requirements to me by reading DOS Clipper code aloud, was mystified by the whole client-server revolution, and impressed at what we could get done by leveraging the desktop computer to do some of the number-crunching required for this system. It turns out that, since everyone had increasing amounts of CPU power on their desktop, this newfangled client-server thing meant reduced costs in owning and maintaining mainframe server assets (which, in most cases, could be pushed off the nearest cliff).
This was the mid 1990s, and the government was finally catching on to this whole client-server thing. But the web revolution was brewing, and the hottest new language, Java was about to change everything. You see, client-server solved a lot of problems, but introduced a new one: version inconsistencies in the client could break your server. This meant paying strict attention to Progressive Enhancement, that paradigm in which each new change is magically backwards-compatible (or, at a minimum, wouldn’t break things for people on older clients).
With Java, though, this didn’t matter: since the applet actually lived on the server and was distributed via the web, each client would download the latest version of the software at the start of every session. But what about the server? In the database, subsequent enhancements to the data model have to be done in a way that prevents corruption or integrity problems in the existing data. So we still had to obey the Gods of Progressive Enhancement, lest the whole thing come crashing down around our heads.
Eventually, the N-tier system won out, and today we have the familiar architecture of browser (view-only client), web server/app server (functional/procedural business logic), and database (data storage and integrity rules), with other services thrown in as needed (server-side observers/notifiers, periodic taskings, etc.). The so-called Services Oriented Architecture can be thought of as a bunch of highly promiscuous application servers existing in a series of XML-over-http-wrapped cocoons. It’s still N-tier, but N is a really high number indeed.
Throughout all of this, the paradigm of Progressive Enhancement remained: there’s always *something* out there relying on your service continuing to meet the contracts you established when you published the service. There’s a reason that features are deprecated long before they are removed. And there’s a reason why languages and platforms are pilloried for breaking older code (I’m looking at you PHP 5.3, and you, Python 3, and I just don’t even want to look at Facebook).