Friday 6 March 2015

Continuous Deployment and Programmers on Call

Two days ago I was attending an interesting Brighton Java talk on continuous deployment by Jose Baena followed by a discussion led by James Stanier. I heard about some new tools; got reassurance that what I was doing was also, roughly, someone else's approach; and that the tricky problems were felt by others too.
One of the discussion points was "Should developers always be on-call for their code?". My gut reaction was "always? No! I've done that - 18 months with a pager - no way, it's soul sapping." In the shower this morning I arrived at a more nuanced answer, that (of course) agrees with my gut reaction. The reasons are intertwined, bear with me while I pull them apart a bit...
First, there's some basic pragmatism: What do you do with the code written by someone that left? If you pair program, who's on call - both of you, take it in turns? If I've maintained a method in a class do I suddenly get the entire class?
Second, and leading from that thought, is the issue of who dials the number of the right person? If an organisation gets beyond about 6 people (arguably 2 if you work in layers of a stack) there will be failures where it isn't immediately apparent who owns it. Now you need 1st and 2nd line support. By the time first line has isolated that it is a particular unit which is at fault, not the database or the user interface it connects to, then they are probably in a position to make the fix faster than they can get the 2nd line on the job.
James offered the thought (bait?) on the night that being on call might prompt a sense of responsibility. The come back from the floor (not me) on that was that developers paid for call outs wouldn't be motivated to produce good code. Getting called becomes a source of income. My experience is that after a while, with a decent wage, the intrusion on my life mattered more than the double time. However, to some extent I think he is right - throwing code over a wall to be someone else's problem isn't how I like to work. Even in the 1990s I mixed development, test and support. However, it does lead me to my third point: given the first two issues, it is clear that matching an individual to a block of code is problematic. Many problems require that the on-call person has the sophistication to move up and down the stack, look at systems issues, understand the relationships between the parts. So, maybe the on-call needs to be at a team level. There's still a responsibility. But there's also the responsibility to your team mates' social life, not to mention being fingered for code which was hard to understand and fix!
And there's the fourth point: Yes, feel responsibility for your code. This isn't ownership* though. As a team the power to fix the code needs to be dynamically allocated.
So, being on call - as a team, but on rotation - motivates responsibility and quality. It gives a reason for good testing, code reviews, not sitting in a corner but getting the whole team's work, and seeing the full development cycle that putting development and ops together implies.

* I don't mean avoiding "ownership" in the sense of "I'm going to own this problem", but in the sense of "this code is my precious, it's mine!" or "I'm leaving the company and taking it with me".

1 comment:

  1. Good post! I still haven't made up my mind. But I do like people to feel ownership over their code. I like your suggestions about it being a team responsibility.