Looks like you’re saying that developers can’t discuss priorities with management.
In some companies this might be true.
But in many, when a CTO or a senior dev demonstrates business value of a speedy website, it would get attention.
I’m sure project management doesn’t care about keeping packages up to date either. But most devs can successfully communicate that this is necessary and that the alternative is way worse.
Yes, when I was CTO I did a lot to make our website speedy.
When I was consulting I would often do performance analysis of the sites I consulted at, show how performance improvements could be made, put links to relevant studies on performance improvements and the effects on the bottom line with nice quotes, to have the task of cleaning everything up be put in the backlog and forgotten forever.
>I’m sure project management doesn’t care about keeping packages up to date either.
How many days or weeks does it take you to update a package? It generally takes me a minute, sometimes problems happen and I need to spend some hours but those are infrequent. If a package update is going to take too long it becomes something for project management to be aware of and sometimes it is not allowed to update a package.
But generally issues with site performance need handling over a longer period of time than updating a package, I would think that was evident to anyone that has ever updated a package or done a performance analysis of a site. The comparison between something that generally takes a minute and something that takes weeks seems insincere.
But I can make an example where an update was needed that would take a significant amount of time, the reason that the update was accepted was that it would fix certain bugs with the old package and it needed to be done. Either the package was updated or the bugs were allowed to remain or we could fix the bugs with longer time than it took to update the package. I think it is obvious how this is a different argument than the site performance thing, the package update is an argument that this way we will fix the problems that you the business have pointed out, the site performance thing is an argument that this is a problem we want you the business to acknowledge.
I once worked for a place where the business unit got us to deploy one of those crappy client side A/B testing scripts which blocks rendering. Conversion rates started to dip and the same people came back to us complaining about it. I was able to pull together plenty of evidence to show them what the issue was. All they cared about was if we could A/B test it using the aforementioned client side script. Some people just can't be reasoned with, so glad I got out of that place.
In some companies this might be true.
But in many, when a CTO or a senior dev demonstrates business value of a speedy website, it would get attention.
I’m sure project management doesn’t care about keeping packages up to date either. But most devs can successfully communicate that this is necessary and that the alternative is way worse.