3 ms·

Surely, this guy realizes this is highly dependent on where you're working. Release managers, QA teams, and dev->test->prod issues are absolutely not gone. Argu

Surely, this guy realizes this is highly dependent on where you're working. Release managers, QA teams, and dev->test->prod issues are absolutely not gone. Arguably, dev->test->prod issues are even worse than they used to be if you're utilizing vendor-locked services that are difficult or impossible to effectively mock or simulate, and even worse than that when you're part of a multi-vendor enterprise solution where your service needs to interact with other services you don't develop and that don't actually exist yet because they're all being developed at the same time, in which case you're forced to mock an incomplete spec that may or may not end up actually getting implemented. These new realities the author talks about are the only case if you're making sole source standalone services utilizing only externals that use stable, open APIs or standard protocols.

jcun4128 6y ago
What sucks is when you have all these things that have to run for __your__ piece of code to work and something goes down, it's another team that has to deal with it and they're not available. For example whatever handles oAuth in a local domain/test environment. When that goes down and the entire app/test harness doesn't work... at least there are other domains to use in our case but sometimes those are down too.
- hinkley 6y ago
  If I never have to explain again to someone that it’s THEIR JOB to investigate 500 errors from their code before someone has to come ask them about it, it’ll be too soon. Set some alerts please.
dx034 6y ago
Sadly, some people interpret agile and scrum as getting rid of QA teams. Of course you can release faster if no one has to manually check the feature but it just turns the user into the QA team. And no developer can properly test their own code. I absolutely welcome automated testing wherever possible but for any software with a user interface (including websites) it can never fully replace manual testing.

jcun4128 6y ago

What sucks is when you have all these things that have to run for __your__ piece of code to work and something goes down, it's another team that has to deal with it and they're not available. For example whatever handles oAuth in a local domain/test environment. When that goes down and the entire app/test harness doesn't work... at least there are other domains to use in our case but sometimes those are down too.

hinkley 6y ago
If I never have to explain again to someone that it’s THEIR JOB to investigate 500 errors from their code before someone has to come ask them about it, it’ll be too soon. Set some alerts please.

dx034 6y ago

Sadly, some people interpret agile and scrum as getting rid of QA teams. Of course you can release faster if no one has to manually check the feature but it just turns the user into the QA team. And no developer can properly test their own code. I absolutely welcome automated testing wherever possible but for any software with a user interface (including websites) it can never fully replace manual testing.