I know how to tie my shoes

Recently there have been numerous discussions online about the difficulty of convincing people to try unfamiliar software development techniques that technical coaches and mentors consider useful. The same discussions have been taking place for many years, with no progress. Why is there no answer?

Do people not understand the value proposition? Are they afraid of losing status among their peers (after all, they are "senior" in their present methods and would be "junior" in any other methods)? Are they uninterested in mastering their own profession? Are they simply stubborn? Do they lack respect for the coaches and mentors that they hired to help them? Is it something more basic…do humans behave like processionary caterpillars, mindlessly following the track ahead of them until they die? This sort of thing used to puzzle me (see this, this, and this), and others as well (see for example this and this).

Many people ask to see studies or academic papers that prove a suggested alternative method is viable. Yet, the same people did not consult studies or academic papers when they decided to use the methods they currently use to develop software. It seems unlikely they would suddenly change their minds now because of a study or an academic paper, when they generally don’t depend on such sources of information anyway. My observation is that when people ask for studies they aren’t really interested in reading them and they have no intention of accepting the reported results (even if the studies were any good); they just want to send the change agent off on a wild goose chase to get him/her out of their hair for a while. "We know how to do our jobs. Leave us alone!"

So, what’s going on, then? It occurs to me that it’s really very simple: People change the way they operate when they are experiencing some sort of inconvenience or negative feedback. As long as things are going along reasonably well, people don’t go out of their way to change the way they work. They might occasionally try something new out of curiosity, but basically they just keep on doing things the way they’ve always done them.

I saw a video on YouTube of a guy who could tie shoes in a split second. I saw another video of a method of folding T-shirts in a split second. The techniques are very impressive to see, and they are definitely much more efficient than the way I tie my shoes or the way I fold my T-shirts. I could certainly strive to be more proficient in those skills, if I cared to do so.

To learn these techniques I would have to consciously set aside my assumptions and suppress my habits. Then I would have to practice each step carefully, mindfully, and slowly, until I had internalized the sequence of steps and developed muscle memory of the new techniques. In other words, the same way anyone learns any new skill. It is definitely possible.

But I haven’t tried. All that conscious setting aside of assumptions and suppression of habits, all the tedious, careful practice, wouldn’t be worth it. The thing is, I know how to fold shirts and I know how to tie my shoes. I don’t do those things as skilfully as those who dedicate themselves to the art, but my clumsy methods don’t cause me any inconvenience or negative feedback. My life is not in shambles because it takes me 10 seconds instead of 0.5 seconds to tie my shoes. Things are going along reasonably well.

Someone who does coaching and mentoring for a living might not like to hear it, but the truth is that the majority of people who earn their living by writing software are not fanatically dedicated to perfecting their craft. We met those people back when lightweight methods were first penetrating the market. By now, most people who are new to contemporary methods just want to survive the work week without getting punished and with enough energy left over to enjoy the weekend.

This is normal on the far side of the chasm, where we are no longer dealing with enthusiastic early adopters. If you say to late adopters, "Hey, let me show you a cool way to develop code that may or may not be marginally better than the way you’re doing it now!" most people won’t leap to their feet excitedly, eager to learn and ready to change. They’re more likely to react like Arthur, the moth sidekick of The Tick, whose heroic battle-cry is, "Not in the face! Not in the face!"

You might protest: But this development team does experience inconvenience and negative feedback! They create defects that they then must track down and fix. They create design debt that makes their work progressively harder. They avoid touching existing code for fear of creating regressions that won’t be detected until the code is in production or in the market. They work overtime on a regular basis, and it’s not unusual for them to have to go to the office in the middle of the night to deal with production issues. At the same time, their stakeholders are constantly criticizing them for slow delivery and buggy code. All of this is a direct consequence of the practices they use. How could they possibly think things are going along reasonably well?

Unfortunately, that’s all pretty normal, and most people in the software field are accustomed to it. They don’t see it as a problem that calls for them to change their practices. Most of them probably have a hard time visualizing a different reality. When change agents come at them as if the sky were falling ("Companies must change or die! Change or die, I say! Yaaaahhh!"), they just shrug. Whether it’s because they aren’t having any real problems or just because they are numb, they are feeling no pain. Without pain, there is no impetus to change.

Maybe that’s the reason there’s been no satisfactory answer to the question of how to convince people to adopt different practices. We shouldn’t be trying to convince people to do anything. We should be helping people solve their problems and achieve their goals. If they are satisfied with the outcomes they achieve using their current methods, then there is no problem to solve. It doesn’t matter whether we, as coaches and mentors, would be satisfied with the same outcomes; it isn’t about us. When people actually want help because their present methods are causing them inconvenience or negative feedback, then we don’t have to "convince" them of anything…they are already open to alternatives.