4 ms·

Why are software devs responsible for first level support? Software devs are expensive, support staff are not. Seems like bad business to me.

spinningslate 5y ago
Big fat "it depends" on that. It might be superficially correct (dependong on the scope/skills of "support" staff). Even if there is a meaningful financial difference between the day rates, it doesn't necessarily follow when the process is viewed end to end: 1. If ops staff have limited expertise/authority, it's less likely they can resolve problems. They might acknowledge (so maintaining some aspect of client SLA), or have a limited set of pre-defined remedial actions (reset button). Anything beyond that, though, and it needs the dev team. So it's arguable whether the ops staff provide much value in the equation. 2. As a dev, there's nothing quite like the prospect of being paged at 2am on a Sunday to incentive more robust code. End to end dev accountability isn't a panacea either - but the problem is more nuanced than just pay rates.
- kazen44 5y ago
  also, devs seem to really underestimate the pay support staff makes, especially those capable of troubleshooting deep, low-level and complex issues. this might be less visible on the Dev side, but troubleshooting infrastructure is not an easy to find skill, especially if dozens of moving parts are involved.
  - LilBytes 5y ago
    More power to them. The rest of us 'Ops' guys are slowly transitioning to DevOps Engineers and SRE's and are gladly taking handfuls of cash because I both know how to read hex dumps, and are also smart enough to know your IP address isn't going to change because I replaced your ethernet cable.
- acdha 5y ago
  One of the best arguments for shared responsibility is that it avoids “not my job” thinking. I’ve seen large organizations burn resources and downtime because developers and ops are in an adversarial relationship where nobody has a stronger sense of responsibility for an application working than they do for shifting the blame to their counterparts. If everyone is getting things escalated to them it tends to cut through that cycle.
loopz 5y ago
Often the root cause is in dev code without proper logging and documentation = dev problem. The only way for Ops to troubleshoot might be to sniff the network and make educated guesses, if it's recurring. All that extra work costs much more and halts more urgent production work. You broke it, you fix it.
rswail 5y ago
L1 support are users of the software, just like their customers. If the application doesn't provide them with enough information to do their job, then that's a failure of the application. And by "application" I mean the combined software, release, documentation, runbooks, etc. Not just the latest git tag pushed.

spinningslate 5y ago

Big fat "it depends" on that. It might be superficially correct (dependong on the scope/skills of "support" staff). Even if there is a meaningful financial difference between the day rates, it doesn't necessarily follow when the process is viewed end to end: 1. If ops staff have limited expertise/authority, it's less likely they can resolve problems. They might acknowledge (so maintaining some aspect of client SLA), or have a limited set of pre-defined remedial actions (reset button). Anything beyond that, though, and it needs the dev team. So it's arguable whether the ops staff provide much value in the equation. 2. As a dev, there's nothing quite like the prospect of being paged at 2am on a Sunday to incentive more robust code. End to end dev accountability isn't a panacea either - but the problem is more nuanced than just pay rates.

kazen44 5y ago
also, devs seem to really underestimate the pay support staff makes, especially those capable of troubleshooting deep, low-level and complex issues. this might be less visible on the Dev side, but troubleshooting infrastructure is not an easy to find skill, especially if dozens of moving parts are involved.
- LilBytes 5y ago
  More power to them. The rest of us 'Ops' guys are slowly transitioning to DevOps Engineers and SRE's and are gladly taking handfuls of cash because I both know how to read hex dumps, and are also smart enough to know your IP address isn't going to change because I replaced your ethernet cable.
acdha 5y ago
One of the best arguments for shared responsibility is that it avoids “not my job” thinking. I’ve seen large organizations burn resources and downtime because developers and ops are in an adversarial relationship where nobody has a stronger sense of responsibility for an application working than they do for shifting the blame to their counterparts. If everyone is getting things escalated to them it tends to cut through that cycle.

loopz 5y ago

Often the root cause is in dev code without proper logging and documentation = dev problem. The only way for Ops to troubleshoot might be to sniff the network and make educated guesses, if it's recurring. All that extra work costs much more and halts more urgent production work. You broke it, you fix it.

rswail 5y ago

L1 support are users of the software, just like their customers. If the application doesn't provide them with enough information to do their job, then that's a failure of the application. And by "application" I mean the combined software, release, documentation, runbooks, etc. Not just the latest git tag pushed.