I want to point out a pitfall where developer-on-call incentivizes technical debit. I'm not saying not to do it, I'm saying to be careful of it. The cost of q

I want to point out a pitfall where developer-on-call incentivizes technical debit. I'm not saying not to do it, I'm saying to be careful of it. The cost of quality documentation, management tools, system reliability and intelligible logging is real. You either have to spend it up front or every time the operational attention needs deep institutional knowledge. Having a developer there to catch your application whenever it falls down means the software deliverable can be be opaque to a level that would be unacceptable to an exclusively operations-oriented audience. Loosely related example: the support team for manufacturing/service is our engineering department and I field most software issues. If I'm on site, I can pop down, do a quick investigation, and explain how to get everything running again quickly. When I'm off-site or the issue is at another location, the friction of hand-holding someone through the process is just enough to highlight the places that need enhancement.