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.
7 thoughts on “I know how to tie my shoes”
And when people actually want help because their present methods are causing them inconvenience or negative feedback, often, a little push in the right direction is enough.
I like your observations Dave.
very good reading, thank you. Your observations and conclusions seem to be spot on. I have been struggling to come to terms with the latter for a while, though.
“It doesn’t matter whether we, as coaches and mentors, would be satisfied with the same outcomes; it isn’t about us”.
I think your insights are spot on.
I think sometimes coaches and mentors fall too much in love with their solutions. They push a team or an organization to adopt a new technique even when that technique only solves the least important or difficult problems. I see this often with Agile enthusiasts.
In certain environments such as typical IT departments in non-software development companies, using a new or different software development techniques, which would otherwise make a huge difference in a pure software development company, may have very limited impact on the overall performance/outcomes, even if the approaches are implemented fully and properly.
In such environments, the actual process of developing software is the least problematic. Getting people to make decisions, collaborate with each other, and adopt change is the biggest challenge.
This is because software development in such environment is a business process vs. a purely engineering one. In a non-software development organization, no business process happens in a vacuum. A typical business process will have one or more integration points with other business processes that may require interfacing with finance, marketing, accounting, HR, and others. Getting people to collaborate to make decisions, solve problems, resolve conflicts and getting their buy-in is where the action is as well as return on investment(time, effort, emotional labor).
Fine-tuning the software development processes in such environment may be useful but not sufficient or necessary in the bigger scheme of things even if it is cool and sexy.
Totally agree with your conclusion: “we shouldn’t be trying to convince people to do anything”, but I have one nit to pick:
> the majority of people who earn their living by writing software are not fanatically dedicated to perfecting their craft
Where did this word “fanatically” come from? Why pick this word rather than, say, “professionally”, which leads to the following sentence
> the majority of people who earn their living by writing software are not professionally dedicated to perfecting their craft
…from which one might draw completely different conclusions? What observations lead you to label as “fanaticism” the degree of effort that “someone who does coaching and mentoring for a living” would find appropriate?
Yes, we need to be empirical about our profession’s attitude to empiricism. The reasons why software professionals adopt or fail to adopt practices, the degree of effort they invest in collecting data to justify adoption – those things are aspects of reality.
However, when you start to use labels like “fanatical” or “professional” or “normal” you are moving from observation to judgment – moving up the ladder of inference.
The danger in doing so is that you lose curiosity – the useful urge to find out how the world really is. Once you’ve slapped a label like “normal” on the situation, you no longer feel a burning desire to know the answer to the question “how do software professionals *actually* decide which practices to use, now that I think of it?”
(For instance, I suspect that your claim “people did not consult studies or academic papers when they decided to use the methods they currently use” is only true in a narrow technical sense. If you “popped the why stack” enough times on the question “why does Bob use OO” my hunch is that academia would appear in the chain at some point.)
I find that question interesting – how do software professionals *actually* decide which practices to use. How might we find out more about that?
Good point about the word “fanatical.” Thanks for pointing out the potential implications.
I agree the question of how people choose their methods is interesting. However, I don’t hear people in the trenches talking about academic papers or studies. Ever. Not in 50+ companies over a span of 36 years.
If we “pop the stack” enough times, we will probably discover that the majority of practitioners are not completely self-taught, and that nearly all of us attended school at some time in the past. That’s the academic connection, I’ll wager. It wouldn’t surprise me if that were the only academic connection.