4 ms·

I agree with these points. I'm a big fan of developers being on call for their application. It puts the pain where it belongs--with those building the systems

I agree with these points. I'm a big fan of developers being on call for their application. It puts the pain where it belongs--with those building the systems (modulo lower-level errors--such as power failures or network outages--those should go to the appropriate place). However, that pain should only rest with the development team if they also have the freedom and will to spend time dealing with it. They will have spend time (either a constant tax, or more likely, with occasional sprints) to reduce operational pain. They are in the best position to reason about the tradeoffs and pragmatically reason about priorities. In my experience, this produces the highest code quality and the highest team morale. I also like the rule -- if you're paged during the night, sleep in the next day.

logicalmind 12y ago
I only agree with this if the developers also get to choose the deadlines for the app/features they build. All too often, the higher-ups want a feature but don't want to take the development time necessary to build it properly. And shortcuts are taken all over the place to get the feature done in time. The higher-ups don't care about doing things correctly and don't have any pain when things go wrong. Which makes it more likely to push this sort of behavior. I think developers should build code that fails in predictable ways with useful error messages that a support team can use to solve problems. If the support team cannot fix the problem with the information provided, then a developer should need to get involved. This way, developers only feel pain if the code they write fails in ways support cannot handle.
- yanowitz 12y ago
  I think we should automate recovery for error conditions where possible and change business processes to be automatable where not. If neither can be done for some pressing reason, then the failure condition should be defined as an expected condition that needs dedicated staff to recover. But that cost should be surfaced and tracked and the first and second order approaches should be automation above all. Of course, teams need the authority to solve the pain if they also have the responsibility for it.

logicalmind 12y ago

I only agree with this if the developers also get to choose the deadlines for the app/features they build. All too often, the higher-ups want a feature but don't want to take the development time necessary to build it properly. And shortcuts are taken all over the place to get the feature done in time. The higher-ups don't care about doing things correctly and don't have any pain when things go wrong. Which makes it more likely to push this sort of behavior. I think developers should build code that fails in predictable ways with useful error messages that a support team can use to solve problems. If the support team cannot fix the problem with the information provided, then a developer should need to get involved. This way, developers only feel pain if the code they write fails in ways support cannot handle.

yanowitz 12y ago
I think we should automate recovery for error conditions where possible and change business processes to be automatable where not. If neither can be done for some pressing reason, then the failure condition should be defined as an expected condition that needs dedicated staff to recover. But that cost should be surfaced and tracked and the first and second order approaches should be automation above all. Of course, teams need the authority to solve the pain if they also have the responsibility for it.