It's not just media companies rewriting something significant every few years; everyone in the tech industry does it. There's a very good reason for it: it provides interesting and high-paying work for tech employees.
Who wants to go to a company, set up a great system that doesn't need any more work except maintenance, and then just settle down into maintenance mode? No one who wants a rising career. "Maintained system using $oldTech" doesn't look good on a developer's resume, whereas "migrated critical system to $newTech" does.
And it's not just the developers: managers who oversee big teams of developers working on a big new project have more prestige and are paid more than managers who just oversee some boring already-done project that's in maintenance mode.
Now, in this case, there were probably very good genuine reasons for making a big change (I'm no fan of MongoDB), but many times if you look closely with a critical eye, you'll probably find that people padding their resume and making up a reason for their job to exist is the real reason something is being done.
Busy-work is never interesting, and if it's "high-paying" someone is getting fleeced (and will do what they can so as not to get fleeced in the future). At some point, the constant rewriting will have to stop. In contrast, maintenance work on a well-engineered critical system can be quite interesting in its own right (and it's not like the "maintenance" doesn't involve writing some new stuff on occasion. Nothing is ever truly "done").
Taking part in a big new project to switch to something else can certainly be interesting, if it's a new technology, and even if it's really no better than the previous technology. If nothing else, it's really good for your resume.
Just to expand on this: if I were to take part in a project to move a critical service from Postgres to MongoDB (which I believe to be a worse solution), this would still be a better learning experience for me than just maintaining an existing installation. I'd have to learn about both DBs, and write a lot of new code to work with the new DB. That wouldn't happen with a Postgres system that's already set up and working fine. And my resume wouldn't look like someone that can come in and get to work on a big project and see it through by working on a maintenance project.
>At some point, the constant rewriting will have to stop.
At that point, the developers and managers who pushed for the big new project will have moved on to another company. Remember, moving companies every few years will generally yield a much higher salary than staying at the same company for your entire career.
>In contrast, maintenance work on a well-engineered critical system can be quite interesting in its own right
Sure, but you're not going to get a great salary doing that.
It's not just media companies rewriting something significant every few years; everyone in the tech industry does it. There's a very good reason for it: it provides interesting and high-paying work for tech employees.
Who wants to go to a company, set up a great system that doesn't need any more work except maintenance, and then just settle down into maintenance mode? No one who wants a rising career. "Maintained system using $oldTech" doesn't look good on a developer's resume, whereas "migrated critical system to $newTech" does.
And it's not just the developers: managers who oversee big teams of developers working on a big new project have more prestige and are paid more than managers who just oversee some boring already-done project that's in maintenance mode.
Now, in this case, there were probably very good genuine reasons for making a big change (I'm no fan of MongoDB), but many times if you look closely with a critical eye, you'll probably find that people padding their resume and making up a reason for their job to exist is the real reason something is being done.