Hacker News new | past | comments | ask | show | jobs | submit login

There's only one version of each library allowed for essentially the whole company, including internal libraries. So if someone wants to upgrade it they may need to update the old codebase's call sites and get those changes approved.



My impression is that the hassle and pain of doing this is often why languishing projects are deprecated. I can't tell you how many times I've read TotT issues or seen threads on eng-misc or elsewhere that would either talking about some new test system and how it handles crufty codebases, or how one should check for dependencies, or what might happen with some internal app that lost its sponsor/maintainer because they either transferred teams or left the company. For a while, even somewhat important things like Dory were un-maintained (after Moh Musa left Google), and lots of times it's happened that reorgs caused deprecations.

Seeing how those sorts of things play out in actuality, it doesn't surprise me that unpopular or unprofitable products are killed rather than kept on life support. Lots of times, the people who would have to fight for them don't have the political will (or maybe even complete history of the product) to commit to staff allocation to keep them alive in the face of the alternative: chasing the next 10x dream.


The weight of managing depot wide upgrades are definitely not a factor in turning down customer facing services. In 10+ years doing low level libraries and infrastructure no one ever used my teams efforts as a reason to sunset an offering.

Although depot migrations are tedious, the burden of doing them for all but a subset of mothballed systems would not significantly changed my life.


Also, generally speaking, because the model is "library owner makes the LSCs," library consumers are happy to accept small/reasonable changes in API usage.

Off the top of my head I can only think of one time when an internal library deprecation caused a huge ruckus: some front-end framework was deprecated which led to a huge push to rewrite many of Google's internal websites.

When I left even BigTable, MapReduce and other services are still supported even though they have been deprecated and their replacements (Spanner, Flume) had been GA for more than a decade. (Although their API calls may just go through a translation layer, not sure.)




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: