How to transform COBOL programmers into modern day programmers

Question

I'm working in a corporate environment where the mindset is hugely dominated by people who started programming with COBOL IMS and CICS. Today most of them program with more modern languages like Java. But If you look at their code and design decisions not much has changed

• methods many screens long
• a huge amount of global variables or their modern incarnation the singleton pattern
• about 30 variable definitions at the start of the method
• globals instead of parameters
• instead of using a factory method a huge switch statement
• misusing of database table columns because "there was enough space left"
• ...

These people are not dumb most of them are very smart. But explaining to them modern coding practices feels like describing colors to a blind man. Do you have any experience or tips to teach them a more modern approach without affronting them?

Answer 1

Buy them a copy of "Code Complete" and have them write a book report.

Answer 2

The best way to learn how code should look is to read good code. Try to set an example with your own coding style and gently point out their mistakes during code reviews. It's essentially just a matter of perspective; like the saying goes, if the only tool you've got is a hammer, every problem looks like a nail. These programmers view everything in terms of the languages they have experience in, and so even when writing Java, their thought process is in COBOL. Their coding style is merely a reflection of their thought process.

Barring that, have everyone read Code Complete.

Answer 3

Have them write Java; and have strong code review standards. When their multi-page method doesn't pass the code review because it's not good code, explain to them why it's not good code. At some point, they may become annoyed; I don't think it's really possible to change habits that have been "set in" for a long period of time without some annoyance. But as long as the reviewer(s) remain reasonable and consistent, they'll begin to see the point over time. Experience really is the only solution for this sort of thing, and this is really the only way to get the experience and have it be directed (as opposed to learning from their mistakes).

Answer 4

My realisation that there would possibly never be a meeting of minds between me and COBOL programmers came many years ago when I was an instructor teaching commercial training courses on C and C++. I had just completed the section of the course on malloc() and free(), to the general satisfaction of most of the punters, when the one COBOL guy on the course came over and asked:

"But what is this 'memory' stuff? And why would I ever want to use it?"

To be slightly more constructive, ny experience is that COBOL programmers have been trained to think about two things:

• the record
• things you do do to the record

This is actually not too far from OO, and I think the basic idea you need to get across is that there will be subtly different types of record, with different things you need to do to them, and the best way of dealing with this is to put the record and the things that need done together to create objects.

Answer 5

As well as Code Complete (probably after that), have them read Refactoring: Improving the Design of Existing Code (at least the introduction). It discusses both standard code smells as well as how to fix them.

It does sound, however, that what they need is an overview of how to think in an object-oriented manner. I'm not certain what is the best book for that.

Answer 6

Use one counterexample at a time with the words that explain why your way is better, less painful, helps them get home to their families on time, etc. It's very important to go one at a time, though, if you're really trying to grow a culture organically. Some examples:

• Very long methods: See, I looked at your long method and realized that you are using the same logic in two places. I broke that out and now you don't have to type the same code two times. Plus, we only have to test that part once.
• Global variables and many definitions at the start of each method: See, I've moved your variables closer to their point of use. Now, this test code that I wrote that side-effects your code with a system-killing null pointer isn't able to side-effect mine.
• Giant switch: Sometimes, a giant switch is very hard to avoid (and sometimes you shouldn't). That said, if you're trying to construct an object, the word "factory" is telling. See, my factory method effectively does the same thing as your factory but I let polymorphism (for example) replace some of the switch-case management. Less code = less bugs = we get home on time.

BTW, I have never had any success assigning reading assignments to engineers (though Kathy brings up Refactoring, which is an excellent source for exactly this sort of thing). What works for me is for me to read the books, use the suggested techniques, demonstrate the success and how it's making my life easier and then, when the frustration of "how is it that you know how to fix all these things?!" sets in, tell them that there's a how-to book. The smart people will rip it out of your hands so fast, you'll loss skin in the process.

Answer 7

Can you get them started working on good code somehow? Doing small changes?