I tend to agree but I think what’s driving this stuff lies in the changing software product- and project - culture, and the glue-like nature of modern work is an outgrowth of that.
On the engineering side we’ve fully embraced the ephemeral, disposable nature of code, which tends to run counter to business needs which may require hastily constructed code hack jobs to stick around indefinitely. Really makes taking pride in workmanship impossible. You’re allowed to feel good about what your company is doing, but if you feel good about your code then perhaps you’re indulging yourself on company time and could be more productive... so you end up feeling guilty about doing good work.
I also think over the last 20 years there’s been a concentrated movement to remove technical expertise from the product design process. Engineers are present to provide estimates and gauge feasibility, but aren’t granted much leeway beyond that. Decades ago, you needed dev skill to actively shape technical projects since there wasn’t even that much user-level experience with computers and technology to make judgements.
This loss of balance tends to mean software is driven forward almost exclusively by either new features or redesigns. Technical enhancements are rare, unless they exist to support existing features. Nobody wants to spend a few sprints on "Make this thing feel 30% faster" or "Deal with our memory usage issues in these cases" until it reaches crisis levels or customers complain. So you get bigger, bloated software that runs slowly because nobody is authorized to make anything faster or use less resources until a product market position is threatened because of such technical deficiencies.... although sometimes the answer by product leadership to such problems can be even more features.
On the engineering side we’ve fully embraced the ephemeral, disposable nature of code, which tends to run counter to business needs which may require hastily constructed code hack jobs to stick around indefinitely. Really makes taking pride in workmanship impossible. You’re allowed to feel good about what your company is doing, but if you feel good about your code then perhaps you’re indulging yourself on company time and could be more productive... so you end up feeling guilty about doing good work.
I also think over the last 20 years there’s been a concentrated movement to remove technical expertise from the product design process. Engineers are present to provide estimates and gauge feasibility, but aren’t granted much leeway beyond that. Decades ago, you needed dev skill to actively shape technical projects since there wasn’t even that much user-level experience with computers and technology to make judgements.
This loss of balance tends to mean software is driven forward almost exclusively by either new features or redesigns. Technical enhancements are rare, unless they exist to support existing features. Nobody wants to spend a few sprints on "Make this thing feel 30% faster" or "Deal with our memory usage issues in these cases" until it reaches crisis levels or customers complain. So you get bigger, bloated software that runs slowly because nobody is authorized to make anything faster or use less resources until a product market position is threatened because of such technical deficiencies.... although sometimes the answer by product leadership to such problems can be even more features.