How Do We Help Our Existing Staff Transition to OO?

Your existing staff are probably highly-trained and productive in their current procedural environment.  But how successfully they can be "retooled" and transitioned to an OO environment or agile process is a complex issue. Not only has it little to do with a given staff member’s intelligence or technical competence, but it has everything to do with cognition and motivation.

First, is the staff member cognitively equipped to unlearn and relearn a new approach to software development?  It is an empirical fact that your most senior and experienced procedural developers (this includes VB as well as COBOL, C, and PL/I) will have the most difficulty making the switch to OO.  Your less-experienced data modelers will also have a difficult time moving to object modeling. This is partly a consequence of their thinking one way for so long. After 10 or 15 years of solving software problems in terms of functional decomposition, ER diagrams, data flows and passing data structures to global functions, it is not easy to suddenly shift into an "inverted" way of thinking.  

But I do not want to suggest that this is just a factor of age. As I have taught OO analysis and design courses all over the country, I have consistently found that about 10%-15% of the students of all ages just cannot catch on during the course. In my mentoring experience on dozens of projects I have found a similar ratio among the project teams.  Not everyone can be a concert pianist no matter how hard they try; and not every programmer or analyst will adapt successfully to the Brave New World of objects and components. New technology always creates casualties, and being prepared for this eventuality includes honorable options for skills assessment, job re-assignment or re-training, or even early retirement.

Second, and even more importantly, is he or she willing to make the change? Again, it is an empirical fact that some of your people will resist the introduction of object technology. They may resist passively, or they may resist aggressively, but some will not want to change. Some of your best people will resist the change because moving to a new technology always levels the playing field. It is very threatening to some people to be deposed from a position of recognition and leadership, and having to reinvent and prove themselves all over again in a new job role. Even worse for some, they might find themselves taking technical direction from someone 20 years younger than they.

So, how do you determine if a given staff member is cognitively able and motivationally committed? 

My first recommendation is to ask them how they feel about an opportunity to embrace this new technology.  My second recommendation is to listen very carefully to the answer.

If he says, "Oh, yeah, that sounds really neat. I have heard a lot about OO and I would really like to learn it on a project", you know right away you will have to put jumper cables on him to get him started.  If she blurts out "That's great!  I've been playing with Java at home in the evenings, and I really like the way it provides so much architectural support directly in the language. Would you like to see the simple Contact-Management program I did?" then you know she is already motivated.

How do you know if a (motivated) staff member can cognitively handle the transition?  The only way to be sure is to throw them into the deep water—but not without a life preserver. Get them some formal training to get them over the learning curve of the basic OO concepts and put them on a project with a small team (no more than 4 team members) where they have to contribute and pull their own weight. Bring in a temporary, outside OO expert to guide the team in object modeling and the process of basic iterative development. Use this outside expert to identify who is catching on, and who is not. 

Let me illustrate why this part is very, very important. When I teach or do OO mentoring, I always collaborate with the manager who brings me in to identify the students or team members which have the most potential, or have shown the most facility in object modeling or OO programming.  Sometimes my list of names is similar to his: but usually my list is startlingly different. The manager is quite surprised that the programming "stars" of the department produce only mediocre models, where one or two "ordinary" developers or analysts show exceptional skill at abstraction and assignment of responsibilities.

Two examples of this stand out in my mind. I taught a 5-day OO analysis and design course to 18 employees of a very large insurance company in New England.  The students were divided along clear lines: 15 business analysts and 3 C++ developers. Who caught on best in the modeling exercises I gave them?  The business analysts!  The programmers kept trying to force the object models to represent code. This group stands out for me because each of the teams of business analysts produced incredibly well-formed models very close to the "official" answers, and in one case better than my answer!

In another engagement in which I was attending training with a project team I was leading, the single best modeler and abstract thinker in the course was a young woman who was a geologist and had no computer experience at all! 

Some will make the transition; some will not.  The human damage can be exaggerated or minimized by how the transition to OO is handled within your company. Appropriate and sensitive use of formal training, small teams and proof-of-concept projects allow staff members to learn where their strengths might be best applied, or to discover they have skills of which they were not aware. Additionally, it allows company management to reassess skill-sets within the development organization and take a pro-active approach to filling in needed skills.