Training old timey fortran programmers to better code design. hints? [closed]

Question

I need to quickly train Fortran 90 developers into object oriented design, good coding, and general coding practices to make code maintenance easier and accessible to everybody. Their current style is the usual:

• long routines that do too much
• modules are aggregated in "family mode" (routines that have something to do with different kind of objects who share a common use are all in one module, instead of having different modules for different type)
• huge globals module with hundreds of variables
• general un-greppability of identifiers

This is just out of my head. I did a course to one of them explaining OO and modularization in terms of a Pen (with methods such as uncap(), and members like inkLevel) and I was very successful in diverting his point of view. I also gave him the exercise to code in OO style a very simple textual adventure, where the player can move around rooms. I also introduced the concept of patterns and antipatterns.

I would like to know any hints and suggestions on how to perform this task at best.

Thanks

Answer 1

experienced procedural programmers - if they're good at it - have internalized models of code construction that tend towards object-orientation, but they don't realize it. The same way good database designers tend to create tables in third normal form, even if they've never heard of database normalization.

chances are the big ugly balls of mud you're seeing are ancient artifacts, laden with decades of technical debt and emergency changes.

when teaching OOP to procedural programmers (caveat: many years ago) I found that starting with what they know and what they think is good and building up from there into objects and classes makes it "click" much faster than lecturing on abstract concepts and coding talking animals.

example: a good function uses all of its parameters, and only its parameters. a good data structure contains only elements that are logically related to the 'key'. a good module typically centers on one data structure (or an aggregate) and contains the functions that produce, use, and consume the data structure.

remember that the habits these programmers have developed have served them well (as far as they know!) for a very long time; don't tell them that they need to 'forget all that and start over', that just breeds resentment. Tell them that everything they already know is still correct, it's just reorganized. Then show them how to reorganize it, then show them the benefits of the reorganization.

a useful exercise might be to have them code something simple but useful 'the old way', then walk through the refactoring that would make it work 'the new way'. The Socratic method (asking questions instead of showing them directly) is entirely appropriate for this kind of exercise.

good luck!

Answer 2

As you are well aware, this is far different than teaching college kids the basics of OO. You're talking to people who have written working, deployed code just fine with these strategies for possibly quite some time.

Instead of focusing on the what, I would focus on the why. I think the best way to demonstrate the why is to start with a piece of well-written OO code to which a feature needs to be added. As you extend the functionality of the code, you can demonstrate where it is easy to add the necessary hooks for the new functionality.

Reading OO code is the best way to understand it, in my experience.

Answer 3

This is an answer from a Java background, but I'm sure there are equivalent options elsewhere. I'd get your guys into using JUnit or a similar automated-unit-test piece of kit.

1) I've found a number of 'procedural' people who struggle with the whole transition to OO simply for not understanding where the whole thing 'starts'. A unit test framework can give an easier learning curve rather than having to worry about how Application servers work.

2) Writing good JUnits pushes you towards accidentally writing good OO code... and once you've got the bug you find yourself churning out useful bits of recyclable code left right and center... This sort of thing may well help with the motivation to shift from oldskool to newskool...

In addition, once you've got people into the groove a bit, you can get good automated 'checkstyle' plug-ins for your IDE that will highlight things like excessive file-length, method lengths, global variables etc. etc. so If JUnit or similar can get them over the chasm of wanting to develop in an OO manner, some automated tools can then highlight the areas that want re-working with their new understanding!

Answer 4

I found it useful to use a framework which used OO. I was forced to think about how to use it and wondered why things were done in certain ways. I know it's not the whole solution but it helped me at the time.

The framework I used was the Open Class library for OS/2. Lots of GUI stuff but also collections, string-handling etc. How about getting your guys to use .Net and Forms. They will deal with objects such as Window and Control, will call methods and perhaps notice the inheritance hierarchy.

Just an idea...

Answer 5

Do a simple Animal, Cat, Dog example demonstrating inheritance without writing a single line of code at first. Make sure they understand the concept of Object Oriented Programming before you even begin syntax.

It's easy to try to relate old concepts to new concepts if you try to let them understand on their own, so I would avoid that until you think they understand why they're doing it in that particular way. If you explain it to them in terms in which they can see the advantages of doing it that way, they'd have a reason not to use their old pattern of Fortran.

As for the length of methods, take a long method as an example and then replace pieces of it with bitesize methods with proper naming conventions so you can both demonstrate that long methods are ugly and how they can go about improving the situation.