I’m going through my old email archives, and discovered a note from a project I ran to help a very large US property & casualty insurer to better retool their mainframe-oriented programmers (procedural using COBOL) to client-server paradigms (mostly Object-Oriented Programming using Java). It was an interesting project because the dirty secret was that some people were better than others. One of the other systems architects with whom I worked said of his experience at Bank of America, “Our best COBOLers made the best Java programmers. Good software development is good software development.”
Well, kind of. It’s actually not that simple.
And it turns out that what they found is relevant to Overachievers and Underachievers (those high-potential people working below their capability).
I note the following from Richard A. Johnson, Bill C. Hardgrave, E. Reed Doke [(1999). “An industry analysis of developer beliefs about object-oriented systems development“, ACM SIGMIS Database, 30(1): 47 – 64, Winter 1999]:
Evidence suggests that it takes about six weeks for a programmer to become proficient with an OO language, and about six months to fully understand object development. [Citing Taylor, D.A. (1992). Object Oriented Information Systems: Planning and Implementation, New York: John Wiley & Sons.] Research also indicates that those having years of experience with conventional methods may have a difficult time adapting to the object paradigm, unless they also possess a varied development background and an especially keen interest in innovations. [Citing Pancake, C.M. (1995). “The Promise and the Cost of Object Technology A Five-Year Forecast”, Communications of the ACM, 38(10): 33-4]
Of course one’s personal motivation can facilitate acceptance of OOSD. Research at IBM (Pancake, 1995) found that ‘inquisitive’ developers who are open to OOSD learn OO better than ‘dogmatic’ developers.
[pp.58]
…………………..
The high loading of an ‘OO-Champion’ in the organization indicates the importance of this item. Prior research has suggested the importance of a ‘product’ champion in the adoption of an innovation in the organization (Premkumar and Potter, 1995; Prescott and Conger, 1995). The visibility of the product in the organization also improves its chances of being adopted (Agarwal and Prasad, 1997). Finally, the recommended method for learning OO is through some type of apprenticeship led by a mentor (Pancake, 1995). Mentors help ‘coach’ the developers in on-the-job training, thus reducing the difficulty in learning OOSD methods.
I have to say it: “inquisitive” developers are those with more capability and “dogmatic” developers have less. But both can become decent OOP developers!
One of the findings that came out during my work there was that, duh, OOP is a different way of thinking than the old ways of programming. People who had fully assimilated the structural programming paradigm would simply start writing procedural code using Java once they got out of the classes and got into some work stress. I found it baffling, but I’ve never written in COBOL. I don’t even know what COBOL looks like. I’ve never worked on anything bigger than a DEC VAX.
What they had to do was to show the COBOLers that their old ways didn’t work. But they had to come to the conclusion themselves. It was a real learning experience. They would come up with all the ways that COBOL came up short and (strangely) come up with an outline of object-oriented programming (OOP) on their own. There might be a little directing by the instructor but this is really something that they have to come to themselves. The instructor then says “but here! OOP meets all your requirements today!”
You’re basically deconstructing their knowledge and rebuilding it around object-oriented ideas.
What was interesting was that they refused to return to their old paradigm, unlike the developers who did not have this component to their training. (All other parts of the OOP training was the same.)
Anyone want to take a guess as to why this is still relevant to non-techies?
Image Credit: GPN-2000-000354 Analog Computing Machine in Fuel Systems Building Lewis Flight Propulsion Lab (NASA)