> If the dev doesn't have time to be a commercial web developer then they should hire an assistant.
Some companies that do web development (commercially, internally, or whatever) have tighter release schedules than the cool DevOps style Continuous Deployment that we see the unicorn startups like Basecamp, GitHub, Slack, etc. doing where code can get pushed to production a dozen times a day. The place I work at has governmental regulations and SLAs we have to comply with when we deploy, which puts us on a cadence with something akin to Chrome's release schedule (e.g., Dev is CI/CD, QA is CD, UAT is kept to about once a week, Prod is every 4 weeks with capabilities at a 2 week hot fix window). Additionally, we just don't have the resources or budget available to keep one developer twiddling his or her thumbs all day waiting for new buttons to show up on a browser control that we have to hide or mitigate the impact of.
I completely understand what your argument is, and it's valid. We have QA run integration, regression, validation and smoke tests any time code is promoted up the environment chain that tries to catch issues like this, and we do our best to keep on top of it all. This issue isn't something that effects us, but it shows a reactionary approach to dealing with these issues. Teams that do spend their time reacting to changes like a new button, or an underlying OS update breaking some compatibility or what-have-you have always been a thorn in my side. It's no way to deliver value to their customers since their time is consistently being hijacked from new features to put out fires, which is stressful and leads to burn out very quickly.
Some companies that do web development (commercially, internally, or whatever) have tighter release schedules than the cool DevOps style Continuous Deployment that we see the unicorn startups like Basecamp, GitHub, Slack, etc. doing where code can get pushed to production a dozen times a day. The place I work at has governmental regulations and SLAs we have to comply with when we deploy, which puts us on a cadence with something akin to Chrome's release schedule (e.g., Dev is CI/CD, QA is CD, UAT is kept to about once a week, Prod is every 4 weeks with capabilities at a 2 week hot fix window). Additionally, we just don't have the resources or budget available to keep one developer twiddling his or her thumbs all day waiting for new buttons to show up on a browser control that we have to hide or mitigate the impact of.
I completely understand what your argument is, and it's valid. We have QA run integration, regression, validation and smoke tests any time code is promoted up the environment chain that tries to catch issues like this, and we do our best to keep on top of it all. This issue isn't something that effects us, but it shows a reactionary approach to dealing with these issues. Teams that do spend their time reacting to changes like a new button, or an underlying OS update breaking some compatibility or what-have-you have always been a thorn in my side. It's no way to deliver value to their customers since their time is consistently being hijacked from new features to put out fires, which is stressful and leads to burn out very quickly.