I agree and see this as a side effect of a subtler thing. As people shall be replacable, software is designed and subtly mimics the organization's communication patterns. Features are cut up into the tiniest pieces with clear separation from the start (at least its claimed), and over time whatever change or feature seems overly complicated, won't be done or won't be done in a sane manner because its uneconomical.
You are starting to get software with ticket driven development layered around glue code for existing libraries. I see no problem with libraries, it is just the architecture and vertical understanding that leaves a lot of performance on the table, because refactoring insanity takes resources and a lot of talking, understanding and convincing to be done.
Doing this across big teams starts to have downsides. So one team doesn't have a particular use case implemented or understood it and does not want to support it and you run code to compensate for this.
"Do not fall into the trap of anthropomorphizing Larry Ellison. You need to think of Larry Ellison the way you think of a lawnmower. You don’t anthropomorphize your lawnmower, the lawnmower just mows the lawn - you stick your hand in there and it’ll chop it off, the end. You don’t think "oh, the lawnmower hates me" – lawnmower doesn’t give a shit about you, lawnmower can’t hate you. Don’t anthropomorphize the lawnmower. Don’t fall into that trap about Oracle."
I feel this is so much real. Like if there were two kinds of companies: the ones who deliver, they care about their product but most of all they care about their customers, the managers get their hands dirty and everyone pushes towards the same direction; then there are companies in which you open a ticket and wait for two weeks for something that should take 5 minutes, customers and product don’t matter because you’re focused in cost attribution and no body does anything if it doesn’t come in your JIRA board, the managers are all coming from consultancy companies and all they do is finding someone to blame.
I could go on about this all day. Best meme is when you estimate stories for storypoints and then they haggle with you without changing the content of the story. Meanwhile points mean actual time. Then on another side if you haggled down points, you then have more slots for more points. So you end up getting assigned 3x work for the same time. The blame game starts when the sprints elapse lmao
Storypoints do not mean "time". Time would be too concrete and measurable and would be bad for selling more agile coachings.
Instead storypoints represent "effort". What does it mean and how can it be used to estimate a shipping date? I was told that I just don't understand.
The only ways out of these situations are: a manager that understands what you’re doing; knowing that these “story points” are just indicative and there’s no broken incentive towards gaming them.
You are starting to get software with ticket driven development layered around glue code for existing libraries. I see no problem with libraries, it is just the architecture and vertical understanding that leaves a lot of performance on the table, because refactoring insanity takes resources and a lot of talking, understanding and convincing to be done.
Doing this across big teams starts to have downsides. So one team doesn't have a particular use case implemented or understood it and does not want to support it and you run code to compensate for this.
Best example in a monolith case is oracle...