Bart Hackemack (Southern California Edison) is a Deputy Project Manager in the Languages Project, and so I guess he's kind of my boss at SHARE. He talked about his installation's embrace of object oriented design methods and what this means to diehard COBOL programmers such as himself.

Edison was originally sold down the river on object oriented systems because of the promise for higher programmer productivity. They were also attracted by the idea that they could get more reuse of old code. To some extent, this turned out to be true, but improved productivity by the implementers is largely offset by the extended period of time one has to spend in object oriented design.

But still Edison is wildly enthusiastic about O-O-D. What they found was that O-O-D allowed them to model the business itself, rather than its procedures. The ability to model the business is better for the users. Bart says "this beats all the developer productivity in the world".

When you do an object-oriented design, you try to automate the white collar worker, and not the white collar worker's tasks.

Pay no attention, Bart says, to the theorists who tell you to do (1) analysis, (2) design, and (3) code in strict sequence, because in the real world of object oriented design it doesn't work. Implementers tend to jump around a lot, do some designing, write a little code, find it doesn't work the way they hoped it would, and do some more design. O-O-D is an iterative process, and it makes heavy use of prototyping.

He is fond of what he calls "CRC cards" -- Class, Responsibility and Collaborator. When the system design wizards at Southern California Edison build a new system, it is composed of Objects that represent some tangible business asset. Each object is represented by one or more CRC cards. Each card has a precisely defined responsibility, and a well-defined relationship with other specific cards. The Edison designers like to tack these up on the wall when they are building the system.

The best part about the CRC cards is that they can take the deck to the user when they are doing their first walk-through of the design. The CRC cards directly model the users' business, and the users typically learn quickly how to interpret them. The analyst and the user can move the cards around on the table, talk about their interrelationships, and give the user a real understanding of how the system works. Likewise, the user can clear up the analyst's misunderstanding of the same thing!