Which Comes First: Language, or OOAD, Training?

The order of exposure to things object-oriented is important, because OO is a way of thinking, even more than it is a way of doing. In organizations which have a staff with a strong structured legacy, the danger of only introducing an OO language into the culture is that only the language—i.e. the tool—will have changed. I have seen this multiple times in Powerbuilder as well as C++ shops. A flashy Integrated Development Environment (IDE) is introduced, the programmers are trained (perhaps) in the language and set loose to save the company’s bottom line with OO. A casual examination of the code, however, reveals all the blemishes and flaws of the earlier non-OO projects, deceptively dressed up in a bright, new language. Under the pressure of deadlines and exaggerated expectations, it is natural to fall back on what you know, and try to address the problem using the familiar tools and concepts with which you are most comfortable.

Providing developers with a C++ or Java (or Powerbuilder) IDE does not make them OO programmers. Object-oriented languages enable OO-software development but do not in any way guarantee it. Even Java, in which everything is a class or object, can be twisted to produce code that violates every almost major goal of OO software development.

The transition of a software group into an OO world must be part of a systematic transition plan for the larger organization. Object-oriented programming works best when the design, architecture and problem statements are characterized in object-oriented terms. Not only your programmers, but your analysts, managers and user interface specialists must learn to think in terms of objects, and to express their ideas in the language of objects. Formal training of your teams by experienced OO practitioners is a must. If you believe training is too expensive, you are absolutely right. But be honest and confront the question "what is the cost of not training your teams?"

Formal training assures that each member of a team:

• has the same, minimum level of exposure to OO concepts and techniques,
• shares a common vocabulary and notation for communicating with other teams and with the customers,

• gets a concentrated burst of knowledge to get them moving in the right direction immediately.

Once your developers learn to think in terms of objects, then a language like C++ or Java is just a tool—admittedly a very helpful tool—to support the implementation of these object concepts.