29 August 2013

A Pain Problem

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?

27 August 2013

Adaptability

Recently on Twitter I was part of a conversation about how software developers become locked into their tools to the point of religious fanaticism.  Now, don't get me wrong - good tools make developers more effective, and the extent to which developers learn how to work effectively with their tools amplifies that.

What strikes me as odd, though, is that we work in an industry in which change isn't just normal, it's expected.  The rate of change continually increases, and shows no signs of abating anytime soon.  This is odd because developers seem so unwilling to consider changing their tools.

My perspective on that may be skewed by the fact that I spent a good deal of my career as a contract developer.  Usually I walked into a new gig and was shown to the machine I would use, told which development environment the team used, the source control system, etc.  I simply had no say in the matter.  I had to adapt, or I could find a new contract.  I can say, unequivocally, that I never left a contract because of the tools used.

Here's a quick breakdown of the environments in which I've worked since I first started writing code:

30 Years Ago (1983)

  • Command line on an Apple ][, writing BASIC and assembly code
  • Very few editing features, but ignorance was bliss
  • A year later at university it was sed or a similar editor on the school's mainframe writing FORTRAN

25 Years Ago

  • xedit on an IBM mainframe with REXX
  • it was a decent full-screen editor which could actually be automated to provide full-screen UI's for mainframe apps
  • I also used vi on Unix for a number of things, which felt very clunky and backward compared to xedit

20 Years Ago

  • Used the editor from Microsoft C for, not surprisingly, C as well as a couple of other languages
  • The editor was very 'comfortable' to use and I became quite familiar with it

15 Years Ago

  • Worked within the Powerbuilder, Visual C++ and Visual Basic IDE's
  • It wasn't efficient to edit outside of those tools, and indeed was somewhat risky
  • Became comfortable & proficient with all of them
  • The IDE editors were good enough to get work done
  • Also used vi when running remote shells on Unix systems

10 Years Ago

  • Various Java IDE's - PowerJ, JBuilder, Eclipse depending on the standard at the client's site
  • Executed tests within the IDE
  • Used Textpad for text editing outside of the IDE
  • Used vi when in terminal mode on a remote host

5 Years Ago

  • Used Eclipse and NetBeans for Java, Visual Studio for C#
  • Executed tests from the IDE
  • Used Textpad for other text editing
  • Used vi when in terminal mode on a remote host

Today (2013)

  • Sublime Text 2 for both text and code editing
  • Execute tests from the command line
  • vi when in terminal mode on a remote host

What's interesting about the last entry is that I feel like I've lost some of the features that I liked in the IDE's I used going back 15 years.

Sublime Text is really, really fast at indexing and searching through the text in thousands of files, but that pales in comparison with the ability to find the definition of a method in Eclipse, or to traverse a class hierarchy.  I can write macros in Sublime that will automate repetitive operations, which I liked in Textpad and sorely missed in the IDE's, but I don't have the automated refactorings that are available in Eclipse and NetBeans.  I currently work in the Ruby/Rails world, and gave RubyMine a try - it simply choked on the size of the code base I threw at it, and just wasn't viable in this context.  So, all searches and refactoring efforts are manual.

When I observe developers working in vim and emacs, I feel like I'm watching a virtuoso performance by a pianist - they make it look so effortless!  That's fantastic, and these developers do work very quickly in those tools.  What strikes me, though, is that it appears that those tools are optimized for writing code, and less so for exploring and refactoring.

The mere suggestion that developers look at using a tool different than the likes of vim and emacs requires a full body Nomex suit to protect one from the flames that will ensue.  However, my experience has been that it's actually not that difficult to adapt to new tools as they come along.  It does take some time, learning and un-learning but the flexibility is worth it in the end.

After all, it isn't the strongest or fastest or even the most intelligent species that survive - it's those which are the most adaptable to change.