Out of the hands of the technical specialists

The second important consequence of object oriented programming was that it took the main system design out of the hands of the technical specialists. Designs could be managed at a higher level of organisation: a level not cluttered up with a myriad of technical detail. Systems engineers, could concentrate on the larger issues of system design with no need to be technically proficient in the finer aspects of computer programming. As long as they had enough knowledge to be able to communicate sensibly with speciality programmers, they could treat projects simply as systems of communicating black boxes.

Unfortunately, the birth and evolution of object oriented design occurred mainly in large, traditional Industrial Age corporations, where hierarchical management structures were still in vogue. It was anathema to treat the programming and the modules as black boxes in a literal sense. Managers wanted to look inside, have a say in what went on in the black boxes. Corporate dogma required procedures and standards. Managers looked into the boxes and wanted to see how they were coded. They wanted neat and formalised layouts, with approved coding conventions. The black boxes had to conform to regulated, top down structured design specifications.

In this way the full value of object oriented design was lost; the technique was compromised. The regimentation and standardization broke the most important principle of object oriented design that all modules have to be encapsulated: insulated against any outside interference.

The usual reason given for standardization and design regulations is that somebody else at a future date may need to be able to look at the programming to see how it works. Somebody else may have to change or alter the code after the programmer has left the job. It all seems so perfectly reasonable to the thinking of an Industrial Age. But, in terms of object oriented thinking, it is sacrilege. Nobody other than the original designer should ever be called in to repair or change a module in an object oriented environment once it has been created. If it isn't working it ought to be discarded: not changed or interfered with. This is a very hard principle for the mind of the Industrial Age to accept.

So, instead of object oriented techniques freeing up programmers, to do whatever they wanted to in their black boxes, it hampered them with rules and regulations. The elegant simplicity of object oriented programming strategies was corrupted and turned into a complex and inhibiting procedure.