Control Totemism

Management had a trainer come in this week to teach OO. I've been sitting in periodically to see what our trainees are learning. The trainer got to CRC and mentioned that he didn't care for it much. At the break I told him that I had had that experience at first, but I was getting over it. The strongly logical feel of conceptual data modeling appeals to me, but I know that it can back you into corners.

At OOPSLA97, I attended a tutorial by RebeccaWirfsBrock. It made me very uncomfortable. Everything seemed so fuzzy and nebulous, but I kept kicking myself. "There is a reason you are uncomfortable, Mike. This is a blind-spot for you; you have to get over it."

At DesignFest our team had a terrible rift between people who were talking about responsibilities and people who were talking about proper subtyped representations of problem concepts.

I look around at times and I see people who want to do BigDesignUpFront. It is hard for them to believe that there are simpler ways of doing things.. to want simpler ways. CRC couldn't work. It is too simple.. it is for beginners. You can't just go in and solve the problem, that would be too easy. After all, you are not allowed to change your mind once you commit.

Maybe it is language. C++ isn't as malleable as Smalltalk. I am stunned at how often I realize that many people in the Smalltalk community have had insights into object-orientation, early, that still are not widespread in the rest of the OO community. I'm arriving at ResponsibilityDrivenDesign backwards, but how long ago was it discovered? How much has OO been diluted from the little changes in translation? What would have happened if the database people hadn't gotten involved? Would we have happened upon associations with multiplicity annotations and ER-ish object modeling?

Maybe it is left-brain versus right-brain. CRC is great, but it is touchy-feely, humanistic. If we were that people-oriented we would have picked a different line of work, right? Engineers want hard binary solutions: yes or no. We prefer the static models; we can pin them down. We solve the hard problems, and we'll make them hard if we have to. And once we think that we have them in a can, we'll pass them out to people who are good at following orders.

-- MichaelFeathers (just rambling)

Well put, Michael. --RonJeffries

I also echo the well put. --SamGentile

I caught onto CRC as a C++ user in about '92 and it helped me get the object AhHa of small simple classes/methods and so on. Language/development environments may have some role in ease of refactoring, balancing design time before code time etc. but I don't think the fundamental class/responsibility/collaboration level design need differ much among the languages people do this stuff in.

The precursors of the UmlCaseVultures at that time were all coming from Ada (and the DoD culture etc.) and I wondered then if that had to do with the heavyweight emphasis on BigDesignUpFront, heavyweight formal methodology etc. I still don't know what it is, but I've tended to find that there people pushing those concepts most heavily are coincidentally selling them (or training in them, tools to do them, etc.), and the people buying into them are less (in my no-doubt limited experience) the engineers than the managers a rung or three up. There probably aren't many training firms teaching extended expensive seminars on CRC...

I don't think of CRC as touchy-feely or more people-oriented than the more formal alternatives. I'm about as un-people-oriented as they come, but design is (to be most effective, for me) a team activity. CRC-style sessions (can?) become play-acting as objects rather than purely interpersonal interactions (Hmm: play-acting problem solving in a largely imaginary universe: perhaps there's something in the similarity of stereotypes of programmers and RPGers?) --JimPerry