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.”

Oh.

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.