Notes from the meeting

The evening started with a hint of humor and excitement – the article’s tone was direct and people in OTUG were eager to say what they felt about it.

 

The meeting began with both the moderators introducing themselves and welcoming the audience. Attendance was 20.

 

Gary explained the “rules of engagement”. Summary of the article was given (see-attached document) with the intent of discussing 3,7,9,11,15,20 in the Fishbowl Panel.

 

As the discussion went along, a general pattern evolved. After discussing each topic, a poll of the participants would be taken to see how many believed in what the author proposed and how many believed otherwise.

 

General Comments on the article

 

The discussion started with general comments about the article per se. Apart from the strong tone of voice the author has presented his views in, the attendees agreed to the fact that there was a general confusion about the subject of the article. There was a general consensus that the author of the article, although is specifically using the term OOP throughout the article, is using OOP interchangeably with Object Orientation (OO).

 

After the brief initial comments, Gary expertly shepherded the discussion to the pre-decided agenda.

 

 

The GoldFish Bowl Discussion

 

¨       Land Of Confusion

 

“Land of Confusion”(Summary point 3) was the first topic under discussion.  In three brief paragraphs, the author had concluded that

 

 

- “OOP technology has generated more confusion than almost any other computer technology.”

- “It has almost become like Particle Physics, in which only a small elite group appears to understand it properly, and everybody else needs years of meditation and practice.  Even OOP’s goals are not clear.”

- “Further, little is known or agreed on about whether OO’s benefits are mostly limited to large projects, or all project sizes.”

- “There is also a lot of mixed opinions about when, where, why, how, and if OO works better for some domains (industry types) over others.”

 

 

In response to the above mentioned opinions of the author, the following discussion ensued:

 

Since most of the attendees were OO experts working in the industry, they accepted the inevitable suggested by the author and gave reasons for the confusion surrounding the OO world. Lack of training was determined as the leading cause of this confusion. Furthermore, it was acknowledged that even experts in the OO fields have not been able to come to a consensus of what exactly constitutes the OO Paradigm. The discussion moved on to include processes and it was mentioned that marketing hype using words like “OO Processes” further complicated the matters. “There is no such thing as an OO Process” commented one of the participants of the fishbowl discussion and the group agreed. It was also recognized that 70% of the developers in the IT industry are confused regardless of the technology or paradigm being used. This, as cited in various studies, is due to unclear requirements or too volatile requirements. Also, the human weakness of  “Everything is initially confusing” was acknowledged too. Change, however small, is resisted by human beings and the OO paradigm being such a big change, has been looked at being confusing and complicated.

            As far as application of OO principles in varying project sizes and industry types is concerned,

one of the participant quoted Jacobson “OO applies in some situations better than  the other “ . This, the group agreed, is specifically true for industry types. It was further acknowledged that OO builds understandable systems and is an organizing principle, abstracting and detailing as needed.

 

The Poll:

 

At this point, Gary took a poll of the participants asking how many of them thought that OO was confusing. 16 out of 20 answered that it was Less So whereas 4 still believed that it was More So.

 

 

 

¨       Protocol Coupling

 

“Why OOP Reminds me of communism”, yet another attention grabber by the author talks about Protocol Coupling (Summary point 7). This formed the second point of discussion. The author, in strong words, says that

 

- “This reminds me of the tendency of OO to rely too heavily on Protocol Coupling.  In OOP this is where one class depends too heavily on the interface of another class.  One cannot understand the first class until they understand the second.”

- “Thus, you have a ‘grok-breakdown’ chain-reaction in the heavier classes, and mild confusion in the lighter ones.”

- “It is true that protocol coupling is indeed not necessary in OOP, as OO apologists happily point out.  However, removing it from OOP programs make them look less and less like OO and more like procedural programming.”

 

 

Led by Stephen, Coupling was strongly defended by OO enthusiasts present for this discussion. “Coupling leads to better understanding of relationships, provides for implementation hiding through API and increases reuse” – these were the major factors discussed in favor of Coupling. It was duly noted that coupling is a character of procedural and OO alike and should be lessened in either paradigm.  More than a few participants seemed to agree that the author had gotten the notion of protocol coupling in OO backwards.

            Protocol Coupling discussion drifted to “Not Table Friendly” (Summary point 4) another small point mentioned in the author’s note. The author says that

 

 

- “OOP often does not map well to relational databases.”

- “In business applications, most object instances are actually equivalent to fields and records.”

- “Why have an extra layer dedicated to converting one paradigm to another?  There is nothing wrong with layers as long as the purpose is to hide low-level details from the programmer or code maintainer, but these mapping tools are translating from one high-level paradigm (relational) to another high-level paradigm (OOP).  Thus, they are not improving the system, only unnecessarily complicating it.”

 

“Impedance mismatch has always been a recognized problem in the software industry “, was almost everyone’s viewpoint. It was, however, noted that the OO Paradigm has given a viable solution to the problem – “OO Databases” which due to market and business pressures are still not widely used. Several members still reserved the thought that the mismatch might have been solved for CAD/CAM applications where OODBMSs are used extensively and rightly so, but general enterprise business apps still face that problem. 

 

The Poll:

 

At this point, Gary took a poll of the participants asking how many of them agreed to the fact  that OO has too much coupling . The decision was unanimous – everyone agreed that OO does NOT have  too much coupling.

 

 

 

¨       None of our business

 

Under this heading (Summary point 22), the author echoes his sentiments as follows:

 

-        “The real world does not change in a hierarchical way.”

-        “There are multiple, orthogonal aspect grouping candidates.”

-        “OOP’s granularity of grouping and separation is often larger than actual changes and variations.”

-        “There is no objective, open proof that OOP is better.”

-        “Many of the past sins that OOP is trying to fix are people and management issues (incentives, training, etc.), and not the fault of the paradigms involved.”

 

 

 

Although only a few lines, the author managed to make strong statements, agreed the group. How it relates to the OO Paradigm was still a confusion in everyone’s mind. Nevertheless, applying good code and design practices like refactoring were discussed in the business-programming context. With an industry case study of approx. 5000 tables in a business application, the participants agreed that although iterations as part of the development are generally not bad, refactoring persistent data iteratively is a bad idea. Architectural vs. Application level implications of the OO paradigm was discussed from a business-programming standpoint.

 

 

The Poll:

 

It was poll time again.  Gary took a poll of the participants asking them if enough attention was give to business under the OO Paradigm. The decision was 19 in agreement and 1 still convinced otherwise.

 

 

¨       Modeling the real world

 

The last part of the fishbowl was the most interesting one. The author as part of his note (Summary point 20 ) presents the following views:

 

-          “In the real world, associations between behavior and physical objects is fairly weak and highly dynamic”

-          Real world objects do not have a list of predetermined ‘proper’ behaviors associated with them, which is essentially what OOP does”

 

 

Led by Gary, the discussion group responded with a lot of stimulus to this particular topic. Everyone in unison agreed that OO promotes and requires modeling the real world. As part of this requirement, business knowledge is embedded in the system model. Since modeling is promoted, reuse factors in implicitly as part of system design.

Moving along the discussion of models of the real world, it was a unanimous thought that Good models don’t always reflect real world. Also, that the technical term of “Universe of discourse “ is a better word for the real world, since the term “the real world” is too abstract to model in the confines of given business requirements. It was pointed out that Craig Larman, author of “Applying UML and patterns” and a known OO expert, suggests Pure Fabrication –

“ Assign a highly cohesive set of responsibilities to an artificial or convenience class that does not represent a problem domain concept – something made up, to support high cohesion, low coupling and reuse. “ as a way to fill in the gaps that remain as part of real world modeling. It was further agreed on that in real life, Business modeling consists of modeling a particular viewpoint or state of the real world , since it changes so dynamically.

That “proper” behavior of classes or objects in a system should be ascertained in any paradigm and not just in OO was the prevalent thought. OOP should not be looked as carrying this extra burden, this should happen as a part of any paradigm being used for s/w development.

            Finally, the group agreed that the OO models around nouns and not verbs. This make the model more true and close to the real world as opposed to the procedural world where functional verbs are used for function/procedure naming convention.

 

 

The Poll:

 

The last and final poll was asking the participants if, in their view, the OO Paradigm models the “universe of discourse”. The decision was 16 in agreement and 4 with no replies.