This is going to sound extreme, but I did measure it. Roughly 30% of my time was spent just managing dependency updates for quite some time. That, to me, felt

This is going to sound extreme, but I did measure it. Roughly 30% of my time was spent just managing dependency updates for quite some time. That, to me, felt absurdly high. But, the problem was transitive dependencies and their changing APIs. E.g., the redis-rb gem decided it was going to change its API. I guess that's fine, but I didn't use the redis-rb gem directly anywhere in my code. I did use a half dozen libraries that used redis-rb, half of which that immediately switched to the new API, half of which did not. The kicker was the new gem also had a hard requirement on a brand new version of redis, so you couldn't update the gem without also updating redis. So, naturally, not all gems wanted to update to the new gem immediately. This was a manufactured situation that was 100% avoidable. Semantic versioning doesn't help at all in this case. Namespacing your API does. But, that aside, I now found myself having to submit pull requests for libs using redis-rb when I had never used the gem myself. I certainly didn't save any time and the whole thing felt like a gigantic waste of effort. More recently, I went through this when multi_json changed its API. And the other common situation is gemspec's inability to say gem Y provides the API for gem X or to override version numbers you know to work (much like maven allows). So, a lot of problems that should be simple to solve become matters of wrangling multiple parties to agree on compromises. Since actively pruning my dependency graph and only very selectively growing it, my time spent managing dependencies is mostly negligible.