A few people responded to yesterday’s email about toddler gates, and I loved it.
To recap, we have a gate contraption that doesn’t always get shut when someone uses the stairs, leaving an opening for our youngest to make a break for the stairs. So, likening the situation to production bugs in software development, I went through some hypotheticals of what various levels of teams might do in that situation.
We ended the email with, “What would an A team do?”
I got a couple of responses that I think hit the nail right on the head. I normally like to attribute these responses to those who offered them, but said toddler has not been sleeping well, and we had her at the ER last night, and I focused on that instead of soliciting the permission to name the folks. So, you folks, thank you for participating in the discussion!
First:
Self-closing gate!
Yes! Automation can sometimes eliminate entire classes of problems, and I think it makes sense to apply automation here. There are dangers to over-automating, as Lisanne Bainbridge wrote about (this link is to a PDF of her research paper), but where it makes sense to apply automation, do so. A danger we’d have to watch out for, if we become too used to our gate closing itself, if we went to someone’s house, and they didn’t have a self-closing gate, we might be so used to not paying attention to closing it that we might forget to do so.
What parallel dangers do you see in too much automation in software development?
Second response:
Might I suggest that “toddler duty” might be much more productive than “gate duty”. The gate doesn’t benefit much from having another family member to interact with, but the toddler (and the person on duty) does. It is likely that the stairs are not the only possible “production bug”.
I love this! As it turns out, we don’t care one whit about the gate. It’s the toddler that we care about. We don’t care about production outages—we care harming our customers. If we could have production outages without harming them, then it wouldn’t matter.
The second response continues:
“Gate duty” is likely really boring and frustrating for the person on duty; processes that your people hate doing (although sometimes unavoidable) are much more likely to fail or cause other failures. I would even wonder if the team might prefer the interruption based process to the prospect of dedicated time on “gate duty”.
Analogies can be drawn to QA, on-call duties, and pair programming, but I can think of multiple conflicting versions of such analogies. Don’t make it hard for the team to do what they are really there to do - and regularly remind them what that is so activities and processes can be judged against it. Knowing their purpose will help the team focus on what is most important.
Also, have you considered an elevator? Or a single story house?
So much good in there that if we dissected it all, we’d be over the two minute limit. That last line really brings it home to me. We can change our systems!
In fact, if we want to continually improve, we pretty much have to.
