Hmm, there were some absurdities when I was on the team, but I wouldn't have identified that as one of them. I'd characterise the service count as possibly slightly overboard, but not the deploy count: making changes super-incrementally was absolutely a positive thing compared with other places I've worked, although it would never work without an almost-zero-friction deployment process.
Done right, it avoids bugs - especially complex hard-to-roll-back state-related bugs - that can arise from discrete waterfall-style releases of big and complex features all at once.
Your comment seems to be making a hell of a lot of assumptions and associations which seem very specific to the environment you work in[0], but stated as though you think the entire world must be working in the same way. It feels a bit like a child insisting that they don't speak with an accent.
[0] "One deploy is one feature", "every company has 'BA's and 'PM's" [we had the latter but I'm scare-quoting both because they are far from universal], "each feature has to be 'identified' by said BA or PM", etc. Also, this seems to be written not only from a staid perspective but from a small-co perspective; for large companies, even 3000 features is not a huge number, and wouldn't be more than maybe 5 or 10 per team.
See comment on bugs. Our releases are "frictionless" too, but yes, I am hard-pressed to even imagine 3000 improvements a month to any major brand that comes to top of mind.
Bugs? Roll back. Bugs are generally proportional to LOC, not number of deploys - given that's a DevOps variable and not a programming one – so the only relevant difference I can imagine is less chance of a multi-bug, multi-factorial, multi-dependent, nightmarish-to-fix incident.
Depends on the perspective. Adding one data field to a Kafka record, or Protobuf message, or Bigtable cell, or Postgres table is already an improvement.
There is already so much work to do consuming data from A, transforming it, and storing it into B.
Done right, it avoids bugs - especially complex hard-to-roll-back state-related bugs - that can arise from discrete waterfall-style releases of big and complex features all at once.
Your comment seems to be making a hell of a lot of assumptions and associations which seem very specific to the environment you work in[0], but stated as though you think the entire world must be working in the same way. It feels a bit like a child insisting that they don't speak with an accent.
[0] "One deploy is one feature", "every company has 'BA's and 'PM's" [we had the latter but I'm scare-quoting both because they are far from universal], "each feature has to be 'identified' by said BA or PM", etc. Also, this seems to be written not only from a staid perspective but from a small-co perspective; for large companies, even 3000 features is not a huge number, and wouldn't be more than maybe 5 or 10 per team.