Hacker News new | ask | show | jobs
by another-dave 1065 days ago
Someone who's job it is to oversee development across the comp, just needs to ensure teams treat internal dependencies like they would external dependencies — allow for time to upgrade upstream services as part of the normal dev cycle, never get more than N versions behind etc.

If you're on v37 of a service and your forced to continue to support v1 (and 35 others) there's a problem somewhere.
2 comments
Cthulhu_ 1065 days ago
For one, that there wasn't enough challenging to make backwards incompatible changes.

If it's internal APIs, they need to get on top of deprecating and removing older ones. This is one of the key points of Google's SWE book (at least the first part) and the benefits of a monorepo; if you change an API in a backwards incompatible way, you're also responsible for making sure every consumer is updated accordingly. If you don't, either you're left maintaining the now deprecated API, or you're forcing however much teams to stop what they're doing and put time into a change that you decided needed to happen.

link
Aeolun 1064 days ago
> If you're on v37 of a service and your forced to continue to support v1 (and 35 others) there's a problem somewhere.

I think you misunderstand.

v23 was built on v5, which is built on v1. Re-using the earlier logic was obviously better than duplicating it. v24 is used by an external system that nobody has any control over, so it’s impossible to change. All the other versions… well, no idea if anyone uses them, but everything works now, why invite disaster by removing any?

link