Human Factors And Object Oriented Programming

A great deal of theoretical criticism of OOP as an abstract concept exists already. The HumanFactors perspective on OOP, on the other hand, looks at what sort of behaviors and results OOP encourages. To me, OOP seems vulnerable to criticism on grounds related to HumanFactors in several ways.

First, OOP proposes an undesirable dichotomy between class designer and application programmer. The more senior (and presumably more skilled) class designer is artificially separated from the task of actually binding his work into a useful product, allowing him to simply declare victory in the form of a BlackBox of only hypothetical usefulness. This is sub-optimal because the more skilled programmer should actually be participating in the difficult task of final delivery.

Second, OOP encourages open-ended, subjective debates about such things as class hierarchy. Should "Manager" be a subclass of "Person," "Vendor," or both? These questions sprout like a cancer from OOP's attempt to shoehorn what amounts to relational data into a hierarchical model. There is no right answer to such questions as these, and their abject irrelevance to reality seems, to me at least, to be self-evident.

Third, InformationHiding is sub-optimal from a HumanFactors perspective. The greatest benefit of software is its adaptability over time. Bugs can be easily fixed, and unforeseen applications effortlessly developed for a piece of hardware. Comparatively little is set into hardware, and even the motherboard BIOS of a PC is really reprogrammable software. Hardware, firmware, and OS designs, being more or less set in metaphorical stone, are carefully though-out and made as extensible as possible. InformationHiding , unfortunately, encourages every rank-and-file programmer to immortalize his or her output into a black box consisting of private members operating in unknowable ways. This is not that different from the hardware design, in its (purported, at least) inaccessibility. In so doing, OOP misses the whole point of the software revolution - the accessibility and mutability of its stock-in-trade, even for future collaborators from different organizations.


The thesis of this page is that "OOP seems vulnerable to criticism on grounds related to HumanFactors". OOP is nothing but a programming paradigm. Programming paradigms should have no impact whatsoever on HumanFactors. Programming paradigms are but one aspect of the mere NutsAndBolts by which programs are constructed. Programs may have HumanFactors issues, but programming paradigms do not, because given a set of programming languages of sufficient capability, all can be used to create equivalent programs regardless of the paradigms they employ. As such, any relationship OOP has with HumanFactors is a failing in the development methodologies that employ OOP, rather than a failing of OOP itself. Those same methodologies would be just as subject to criticism, on a HumanFactors basis, if they were used with any other programming paradigm.

By way of analogy, if it is valid to claim that OOP should be criticised on grounds related to HumanFactors, then it must be valid to claim that the colour of the wiring in the walls of a poorly-designed house should be criticised on grounds related to HumanFactors.


RE: Programming paradigms should have no impact whatsoever on HumanFactors. Programming paradigms are but one aspect of the mere NutsAndBolts by which programs are constructed. Programs may have HumanFactors issues, but programming paradigms do not, because given a set of programming languages of sufficient capability, all can be used to create equivalent programs regardless of the paradigms they employ.

I disagree with this position. The nuts and bolts by which programs are constructed must be influenced by the economic realities of our world. This includes the common involvement of multiple interests in large projects, concerns for protection of intellectual property and sensitive information. Flexibility and extensibility of services by end-users, ability to share services (databases, GUIs, etc.), support for mash-ups or accessibility transforms (e.g. screen readers, language translators) of GUIs, etc. - the ease with which these things may be done (and whether they may be done at all) depends heavily upon the nuts and bolts used to construct programs. You can't easily write a screen-reader for a program that displays text via captcha-style postscript as a texture on the wall in a 3D environment, for example.

Paradigms are sold on their presumed ability to support HumanFactors issues. During the OO market fad (a couple decades after OOP was invented) a lot was promised (e.g. it was intended that CORBA and COM would easily allow a federation of distributed objects for extensible multi-enterprise development), but OOPLs failed to deliver (usually due to issues of concurrency control, performance, persistence, disruption tolerance, handling of partial failure, and security). A lot of naive programmers fell for that propaganda. FP has similar phases, mostly involving the not-entirely mythical SufficientlySmartCompiler.

I believe OOP or any other paradigm should be criticized in terms of HumanFactors. But, as much as possible, HumanFactors should be phrased in terms of technical problems or UserStories. If a paradigm is too complex to explain or educate most users in, that's a problem. If a paradigm doesn't allow one to contract development labor off to different groups and recombine it into a working product, that's an issue. If a paradigm does not lead easily to programs that can be safely or securely extended, upgraded, or modified after fielding, that's something to consider. If a paradigm hinders reuse of code or encourages monolithic products that reinvent various wheels, that's a problem. Without HumanFactors, I could point you to a TuringTarpit and call it as good as any other language. (It ain't a failing of the TuringTarpit... it's a failing of your SelfDiscipline or development methodology! See FourLevelsOfFeature.)

I don't disagree, in principle. I disagree only in terms of degree. Programming paradigm seems to have relatively little, if any, impact compared to innumerable other factors, assuming languages of otherwise equal capability. I would argue strongly that given two languages of equal capability in terms of environmental manipulation (which is what I meant by "sufficient capability", intending to exclude TuringTarpit languages and languages of widely differing capability, like Java vs BrainFuck) -- say C# and F# -- the choice of one over the other, assuming developers are allowed to pick which one they prefer, is of almost negligible impact in terms of HumanFactors. That said, I do see your point, and I should have been clearer in making mine. That said, what Beau offers isn't a HumanFactors analysis of ObjectOrientedProgramming. It's a rant against OOP from someone who bought into the 90s OO propaganda, who received less than was promised by a crowd of bright-eyed geeks and unscrupulous XYZ-for-dummies marketers. The cursory claim that InformationHiding is an extensibility issue is indefensible. The claim that OOP leads any to a power-developer writing libraries rather than integrating components more so than do other paradigms (such as FP or procedural) is unsubstantiated. The argument about class hierarchies seems presumptive - it's hardly an analysis of how OOP is actually used in practice by established OO shops.

Oh, and color of wiring in the walls of a house could be criticized on grounds related to HumanFactors; there are reasons for standard coloring (USA: white or green is ground, black and red and other colors typically hot). A house whose wires were all the same color (e.g. white), some being hot and others being grounded, is certainly possible.

I meant from the viewpoint of the inhabitants of the house, i.e., the wiring is internal, unseen by the users of the dwelling.

Indeed. Except, of course, when they want to upgrade the house...


Footnotes:

[1] It may not be as noun-centric outside of domain modeling.
JanuaryTen

EditText of this page (last edited January 12, 2010) or FindPage with title or text search