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
Depending on what you want them to do. it could be a steep learning curve.
you need to minimise the learning curve.
if i remember correctly COBAL is a wordie Syntax (not like C which using symbols to contain its structure) so VB.Net may be the language your team can pick up the fastest.
then have have a look at http://www.learnvisualStudio.net < it has lots of videos
the main series you would be interested in are
Visual Basic 101
Visual Basic 201 - Object Oriented Programming and Design Patterns
this will introduce you to the syntax and a little into Object Oreinted Programming.
then look into the other videos for dataaccess (ADO) slowly progress the skill level. It willl not be an over night thing
HTH
dave
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.
Do this:
public class Foo
{
#region DATA DIVISION.
public string Bar {get;set;}
#endregion
#region PROCEDURE DIVISION.
public void Begin()
{
Bar = "lol";
// STOP RUN.
}
#endregion
}
Oh, and read Code Complete. Then read CLR Via C#. Then start answering questions here. Even the ones you don't know--google the answer, try to work out the answer.
Don't worry, it'll only take a couple years before you feel comfortable.
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.
This isn't a real answer, just a link that I found useful. Most Object Oriented teaching material uses the same old concepts for teaching about objects and classes - the animal hierarchy etc... I find this article refreshing in the sense that it sort of starts with the real juice: how to decompose a system into it's initial classes and objects: http://archive.eiffel.com/doc/manuals/technology/oosc/finding/page.html
I worked once on a .Net project with an experienced COBOL developer and the thing I noticed time and time again was the assumption that data types didn't need to be checked (which is understandable when you've had experience in COBOL, where everything is just really a string of characters tied to some format): the other things were picked up pretty quickly, but that habit took a long time to die.
The most important thing is to remember that .NET is not a programming language. COBOL is a programming language.
If you want to get COBOL programmers productively producing .NET applications, then ask them to review and evaluate VB.NET and IronPython by prototyping some small applications in these languages. Once they have tried VB.NET and IronPython, let them choose which language to use going forward and organize some training in the chosen language.
Whatever you do, do not let them use C# until they have demonstrated that they can handle VB.NET or IronPython. If you have a spectrum of computer languages with C++, Java and C# at the complex, techy, punctuation marks end of the spectrum, then COBOL is at the other end being straightforward, business-oriented, and plain text. Both VB.NET and IronPython are closer to the COBOL end of the spectrum.
If I was running the shop, I would skip the eval and begin by selling them on using IronPython because I think it is a better choice in the long run, and Python skills can be leveraged on Linux/UNIX projects or Java projects, as well as in .NET.
The important thing is to get these guys writing and debugging some actual code that runs on .NET so that they get the feel of it, and can figure out some reasonable ways to handle things that they are familiar with like MOVE CORRESPONDING and level 88s.
[declaration - posting by a COBOL vendor]
As someone who's recently been trying to get to grips with COBOL and .NET myself (especially as a long-time lapsed programmer!, I found the hardest part was understanding the .NET framework. The "words" to invoke a method are pretty straightforward, what's hard is finding the method you want to use! Intellisense in VS is great but you still need to know where to start!
I would also point you to this site where there's a great comparison chart for COBOL vs. C# & VB: http://www.codeproject.com/KB/net-languages/COBOLvsVBvsCSharp.aspx
Micro Focus are doing some really interesting things to make COBOL much more .NET friendly but I'd better not going into too much detail here. Take a look at the Micro Focus web site for more information.