Back Pain and Programming

Old age has made me tend to see the big picture in everything, a world where everything's related to everything else. Today's headline is the failure of imaging (using X-rays, CT, and/or MRI) to improve outcomes in patients with back pain. Which, to me, has much in common with programming methodologies. Have patience; I can connect them.

Back pain has been a snake pit of medicine for years now because a) back pain often gets better even if you do nothing and b) symptoms are highly subjective, so most any treatment can be shown to possibly help a little and c) people will pay big bucks to get rid of the suffering of back pain. It hurts! So, all those factors add up to a field where medical professionals are making big bucks and, truth be told, they are in no hurry at all to conduct a rigorous study of their favorite surgery because it would be a kick in the reimbursement pocketbook if the study showed results no better than placebo.

Now here's a little study about back pain that your local back pain surgeon will never tell you. They tried to figure out what factors predict who will benefit from back pain surgery. After all, no point on cutting everybody open if you can predict in advance which patients are unlikely to feel any better afterwards (besides, they might sue if they feel no better). There were a number of candidate factors they looked at, the obvious medical stuff like exactly which vertebrae looked bad on a scan.

Here comes the study punch line, as it always must. The #1 predictor of whether or not you will benefit from surgery for back pain has nothing to do with your back: it's your psycho-social state. In other words, if you're going through a divorce, your boss hates you, you have few friends or opportunities to enjoy life, etc., then the odds that surgery can fix your back pain are not good.

Now you can try to spin that result in different ways, but just suppose the simplest and most obvious interpretation is true: the root of much back pain is in your mental and social condition. That does not mean your back pain is "all in your head", but rather that back pain is just one of those bad things that can result when you walk around all day clenching your fists, pumping stress hormones, and generally feeling pretty bad about life.

Now to connect the dots. For many businesses, software development is a pain -- in the butt, if not the lower back. However, there are many folks out there waiting to sell your business some solution (new tool, new web service, new methodology, etc.) that promises to reduce your programming pain. Suppose for a moment that, as with lower back pain, a major source of software development pain comes from psycho-social conditions. Maybe the company uses zero-sum bonuses so that if you help your co-worker with her programming problem, you may just be taking bonus money out of your pocket and giving it to her. Maybe the company has an incompetent, top-down review system, so you experience the stress of knowing that you may get a great review for a quarter when you were goofing off, and your worst review when you were working really hard and doing your best work. There are innumerable psycho-social conditions that can help make software development unlikely to go well.

Just like bad back surgeons, that consultant/salesman is happy to sell you something that maybe, kinda, works sometimes for some folks, but in no hurry at all to chip in some funds for a rigorous study that might show their solution is no better than placebo. And make no mistake, there is a placebo effect in business experiments: it's called the Hawthorne effect.

But even though, just like a bad back surgeon, that salesman/consultant can point to some stunning successes, maybe the odds that the proposed cure will help you have little to do with the cure itself, and more to do with what kind of psycho-social shape your organization is in to start with.

But just as with back pain, understanding this may not help. After all, it's much, much easier to buy a new software tool or hire a consultant than it is to make a serious structural change like moving to non-zero-sum incentives, or a review process that identifies poor managers rather than just poor performers. As I will argue in my book, the fact that few programmers or programming organizations can make serious psycho-social changes effectively represents competitive advantage. Those few who can grasp and adapt to the psycho-social forces that make programming harder than it needs to be end up with a business advantage every bit as solid as a patent or trade secret. They won't have to defend it in court, but simply rely on the general difficulty that humans have with change.