I have a number of COBOL programmers who are moving to .NET. I've found many struggle to adopt/understand OO programming principles. I don't have any COBOL experience, so my ability to find what few similarities there are is very limited.
There's no way I want to say "forget your twenty years of experience. This is all new," but I don't have the analogies and tools to do better yet.
What are your recommendation for me to help them understand the .NET world?
I had this problem before as I was a team leader and I had five COBOL developers; they had 4 times more experience in programing general than I had.
As you noticed you have to start from OO programing fundamentals. Then, if you can, try pair programming (one .NET dev + one COBOL dev). This is what I was doing and it worked very well.
This might be useful as well: Microsoft .Net for COBOL programmers
The way to go about this is to think of things from the COBOL programmer's perspective. This is a huge distance for them to traverse so putting out foot stools wherever possible to help them walk is paramount.
Most COBOL programmers will have little or no desktop experience. The will have no OOP experience. Probably little or no networking. Etc.
However, if they have written structured COBOL code they will have a very good feel for what a function is. Even though COBOL paragraphs aren't strictly the same as functions, most good COBOL programmers will grasp that notion quickly. Build on the structured programming concepts that have been drilled into them for 20 years. Structure leads to functions which leads to OOP.
Most COBOL people with that much experience should have very good understanding of business logic. Use that. Get away from the bogus "squares and triangles are shapes" examples of OOP as soon as possible and make them focus on things they might already be very comfortable with - e.g. savings and checking are Accounts and they have these things in common...etc.
They will certainly understand file based programs. Forget about fancy GUI stuff in the beginning. Make them write programs that mimic what they were doing in COBOL but eases them into OOP concepts. They understand records. Records are not very different from structs which are not very different from classes. And so on.
Most COBOL programmers will understand transaction processing. Use that. It should provide a wealth of material to use in teaching OOP and many different APIs of .Net (or any other technology).
Assign an experienced .Net developer as their mentor. Have him do code reviews, be available for advice, etc. Don't just throw a couple of books and a slew of new MS software at the COBOL people and expect them to swim. That's a prescription for disaster. They will need some hand holding and encouragement. But you might well find a couple of solid .Net people in that group a little down the line and keep your knowledge of current systems on board.
Start out by having them use objects, rather than expecting them to come up with a great system-wide OO design by themselves.
You can do what my Intro to CS professor did - design the classes and stub them out for them - just leaving the method implementations for them to figure out. That way, they'll have a chance to get used to the syntax, using objects, scope, etc., without being expected to understand the intricacies of good OO design.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With