Object Oriented: Good, Procedural: Bad, Right?

For all of you old-time RPG developers, remember back when Object-Oriented programming first become popular and it was supposed to be the salvation of maintenance programmers and facilitate tons and tons of code reuse?  I think by now we all know that OO did not save the world, but I think we all do have the general idea that it does make maintenance easier – or does it?

I was reading a research paper from 2007, The Process of Software Maintenance: A Comparison of Object-Oriented and Third-Generation Development Languages, ($) by Michael Eierman and Mark Dishaw.  The authors note that one of the primary causes of software complexity is what is termed “de-localization”, i.e., a call to another code module or function.  Studies have shown that delocalization increases errors of omission and lack of understanding.  One of the “benefits” of OO programming is that it provides more facility for delocalization and, typically, this benefit is used by knowledgeable developers.  Unfortunately it has the consequence of increasing program complexity and the difficulty of maintenance.  Additionally, other features of OO programming, inheritance, dynamic binding and polymorphism, provide further opportunities and dimensions for delocalization – and complexity.

What should RPG developers make of this information?  Really, all developers of new software should be concerned with maintainability as a primary objective. Especially given the fact (which I often refer to) that numerous studies have shown that software maintenance accounts for 70-90% of the total lifetime cost of software.  Who can ignore this fact?!?!  It seems that virtually an entire industry has ignored it.

Again, what should AS/400 – iSeries developers make of all this?  Delocalization adds to complexity, and in RPG, delocalization takes the form of subroutines, procedures (internal and external) and other program calls.  That’s not to say delocalization – often meaning centralization of function – is bad, it comes down to a question of judgment.  And that judgment should consider the fact that writing the code is the easy part.  The hard part comes later when some poor programmer who is unfamiliar with the code will have to maintain it by first figuring out what the heck it does.