Esther Derby posted an excerpt of a Management Consulting News interview with Jerry Weinberg where he answers the question of how to overcome resistance, “Yes. Don’t.” Oh, he says more there, and he can say a lot more on the topic, but that’s enough for the intro to this article.
You see, I wanted to write an article with a shining example of a time when I didn’t try to overcome resistance, but used it to advantage, instead. The problem was that I found myself in the trap that Don Gray frequently mentions, that when someone tells you not to think about something, you can’t help but immediately think about it. So what filled my memory was a time when I had tried, eloquently and earnestly, to overcome resistance on the part of my client.
The system being developed was a Java J2EE system that had been in production for a number of years. It was the system that the development team had built as they first learned Java. It worked well–a real testament to the skill and care the developers had applied. It was, however, rather difficult to extend and small changes tended to make odd bugs pop up in other places. The short description is that the code was very procedural in nature, rather than object-oriented. There was duplication where blocks of code were copied and modified for new features. There was temporal coupling where dissimilar things were being done in the same place because they needed to be done in the same HTTP transaction. There were code objects that extracted values from data objects, operated on them, and put them back.
I could clearly see that refactoring this code into good object-oriented practice would reduce the complexity, reduce the unwanted coupling that caused unexpected bugs, and reduce the time it took to add new features. I wrote up a description of the types of changes I was proposing and made my pitch to the team. As I talked about making these changes (and making them incrementally, as we added newly requested features), I could tell that they weren’t really enthused by the idea. I poured on the heat of persuasion, describing the benefits in the short term of the immediate features we were developing. The less progress I made, the more enthusiastic I became, scribbling UML diagrams on the whiteboard and building castles in the air as I pointed out the advantages in the long term of making some significant changes we knew were coming down the pike.
I got nowhere but exhausted. I stopped, wondering how I could get these procedural programmers to understand the benefits of object-orientation. I was trying to figure out what to say next when a senior member of the team said, “I don’t think there’s anyone in this room who doesn’t believe you when you say this is a good thing to do. We just don’t know how to get from where we are to what you describe.”
I guess I should have asked more questions.
How did I get over this “resistance” to my suggestions? I can think of three distinct ways, demonstration, discussion, and retrospection. The demonstration is focused around what I did, as I provided examples of what I intended and described how I got from the current code to the new code. The discussion is balanced between us, with questions and suppositions and assertions flowing freely in both directions, between peers. The retrospection lay on their shoulders, where I facilitated the discussion while remaining outside of it. They owned what they had learned, where they wanted to go, and what still puzzled them.
What techniques have you used to get across ideas that don’t seem easily accepted?