[Polizeiposaune]

My understanding is that (at least at one point) binaries older than about six months were not allowed to run in production. But APIs are "evolving" irregularly so the longer you go between builds the more likely something is going to break. You really need a continuous build going to stay on top of it.

Best analogy I can think of is log-rolling (as in the lumberjack competition).

[hackernudes]

Google is famously a monorepo and is basically the gold standard of CI/CD.

What does happen is APIs are constantly upgraded and rewritten and deprecated. Eventually projects using the deprecated APIs need to be upgraded or dropped. I don't really understand why developers LOVE to deprecate shit that has users but it's a fact of life.

Second hand info about Google only so take it with a grain of salt.

[zdragnar]

Simple: you don't get promoted for maintaining legacy stuff. You do get promoted for providing something new that people adopt.

As such, developing a new API gets more brownie points than rebuilding a service that does a better job of providing an existing API.

To be more charitable, having learned lessons from an existing API, a new one might incorporate those lessons learned and be able to do a better job serving various needs. At some point, it stops making sense to support older versions of an API as multiple versions with multiple sets of documentation can be really confusing.

I'm personally cynical enough to believe more in the less charitable version, but it's not impossible.

[Hammershaft]

I agree this is an overriding incentive that hurts customers & companies. I don't think there's an easy fix. Designing & creating new products require more relevant capabilities from employees for promotions then maintaining legacy code.