The fact that it's the norm for the builders of mature software to stick around can lead to some gross engineering inefficiencies. For instance, a lot of Everno

The fact that it's the norm for the builders of mature software to stick around can lead to some gross engineering inefficiencies. For instance, a lot of Evernote's backend infrastructure was manually managed [0]: With Evernote, Bending Spoons identified that the backend needed a complete rewrite. They moved from a monolithic architecture running on manually provisioned virtual machines to a microservices architecture with managed databases, significantly improving performance and scalability. It's easy for companies to fall into such pits of inefficiency because climbing out of those pits entails utterly gutting the headcount [*]. I wonder if the same is true at Vimeo, which employed ~250 engineers [1], which seems high for a mature product that's deliberately conservative (most of Vimeo's customers are B2B whitelabelers, for whom a constantly changing product is a massive downside.) It's not like video codecs or storage systems or web standards are changing daily. I would imagine a well-engineered codebase from 10 years ago would work well today with only minimal changes, mostly centered around updating libraries for security patches. The fact that they had 250 engineers on staff who presumably did more than play ping-pong all day makes me wonder if the codebase was not, in fact, well-engineered. [0] https://www.colinkeeley.com/blog/bending-spoons-operating-manual https://www.colinkeeley.com/blog/bending-spoons-operating-ma... [1] https://www.unifygtm.com/insights-headcount/vimeo https://www.unifygtm.com/insights-headcount/vimeo [*] Imagine the equivalent for a building: "we don't have automatic circuit breakers in this building; instead, we have a 24 hour staff of electricians who measure current with an ammeter and manually cut the power if it gets too high."