A while back I had an experience that's the closest a male will get to giving birth - passing a kidney stone. Suffice to say, it wasn't much fun. I did learn something interesting from the experience, though - morphine is wonderful. I didn't encounter any of the common side effects such as itching, and it was a VERY pleasant feeling. The pain disappeared completely and for a few hours I totally understood Keith Richards. I also had no difficulty seeing how people become addicted to opiates.When it was still on the air, I used to watch the TV show House, which was about a brilliant doctor who specializes in diagnostic medicine. He and his team determine what's really wrong with patients when others haven't been able to figure it out. There was a lot to like about House's approach in that the solution to the riddle of an illness was never the result of one person's insight alone, but rather a group effort leveraging the talents and knowledge of each individual. House himself, though, was a classic anti-hero - abrasive, and seemingly without feelings for anyone. He also had a problem.
His character had experienced an aneurysm in his leg which led to surgery that left him in constant pain. House self-medicated with Vicodin to deal with it, and gradually became addicted to the pain killer. In one episode he was confronted and told he had a "pain management problem", which was a euphemism for being hooked on Vicodin. House's response was, "I don't have a pain management problem, I have a pain problem!"
This was a brilliantly simple expression of his ability to look beyond mere symptoms for an underlying cause. If the chronic leg pain was eliminated there would be no need for the Vicodin, addiction notwithstanding.
In the way we work in the software industry, we often experience "pain management problems". The rush of adrenaline we experience when working long hours and pulling all-nighters to meet a deadline, for example, is highly addictive. Like my experience with morphine, I've been there and the exhilaration temporarily makes the exhaustion bearable. Whether it's just your immediate peers who know or the whole world, the pats on the back and the satisfaction the comes with pulling it off have a huge effect on us. Way to go, Dave - you're the ultimate team player! We couldn't have done it without you!
In an emergency situation, such as when your system is down and the phones are ringing off the hook, this kind of response is entirely appropriate. In House, patients weren't immediately sent to the diagnostic group, they had been examined and treated using the normal processes first. The patient was stabilized before digging for the real cause of the illness.
In day to day work, though, the adrenaline rush can create a "pain management problem". House eventually became so dependent on Vicodin that he lost his medical license, spent time in a psychiatric hospital, and broke the law. In building software systems this way, we make mistakes, cut corners, get sloppy and become burned out. The code we produce is of lower quality, and we don't deal with technical debt because we're busy trying to find our next hit of Vicodin. In the end, we and the consumers of our work suffer. Our addiction hurts ourselves, the people we work with, our families and the people using our software.
So how do we deal with the "pain problem" vs. the "pain management problem"? As cheesy as this sounds, the first step is admitting that there's a problem and that we need help. We can simply go cold turkey and refuse to work the crazy hours, but if others are expecting the adrenaline-fueled level of work then that approach won't necessarily fly.
There has to be a system-level effort to deal with the problem and the first place to start is to stop rewarding people for demonstrating the behaviour. While heroics are sometimes necessary, they aren't a sustainable way to deliver software. That said, I totally understand that there are days when you reach a flow state and can work 12 or 14 ridiculously productive hours, but those need to be balanced with time spent not working. Disengagement even for short periods is the biggest step towards "cleaning up". When that extraordinary effort becomes ordinary and expected, the pain management problem has started.
We also need to dispense with the notion that aggressive schedules will focus people on the goal and make miracles happen. How much pain has been created by that idea alone? Good product management includes understanding how little can be shipped that will delight your customers. It also means listening to the development team when they say that a deadline isn't realistic, which in turn means the development team has to be honest about their perception of how long something will take to be built. Even a high-level gut feel is a pretty good indication when the people have experience in the domain and with the tooling. Dan North wrote about that in Blink Estimation.
There must be a truly shared understanding of business problem that's being solved and a cooperative, collaborative relationship while a solution is being built. Hearing statements like, "We have to have this feature to be able to ship!", a couple of weeks before the end of a year-long project indicates that this isn't happening, and puts you in the express lane of the road to the pain management problem. Effective feature slicing is a skill that must be learned not only by the product people but developers as well in order to be able to ship without pressure. Jeff Patton's Story Mapping is a tremendously useful practice for this.
From the developer's perspective, you have to say no when these demands are made which implies that you have to feel safe to say no. The demands are often portrayed as emergencies, but when you have multiple emergencies a week for months before shipping where's the real problem? Saying no is an initial big step towards breaking the addiction, and it something I've written about in the past.
Finally, we need determine how everyone involved in system delivery can learn from their collective experience in order to prevent the need for "crunch mode", "stabilization sprints", "all-nighters" and other symptoms of this problem. While House was a brilliant diagnostician, there was never a situation where he alone solved a case. It was always a team effort, with a small insight from one person leading to a cascade of ideas from others. So, leverage the wisdom and experience of everyone involved to provide those insights. A developer intern might come up with something that leads the group to see a whole new way to ship something that customers have been yelling about for ages. A product manager might have an idea for a simpler approach to a feature which triggers the developers to find a way to build a feature in a day rather than a few weeks. We don't know when and if those moments will happen, but if the whole group is working together and shares the same understanding of the goal then the probability of an occurrence is much higher.
After my kidney stone experience, I was given a prescription for about 20 morphine tablets. I used one when I passed another stone a couple of days after the first, but I never took another one. I increased my fluid intake, adjusted my diet to reduce the amount of oxalates - the stuff of which one type of kidney stone is made - and increased my intake of citrates which helps prevent the formation of stones. Rather than develop a pain management problem by popping morphine every time I had a stone, I dealt with the pain problem by obviating the need for the morphine.
How, in your software delivery world, will you deal with the pain problem rather than creating a pain management problem?
Comments