Educators and consultants as mentors

Dennis Mancl

Lucent Technologies - Bell Labs

Murray Hill, NJ 07974

mancl@lucent.com



Introduction

Educators and consultants are often in a mentor role - their goal is to assist someone who is doing a software development task, in a way that improves that person's ability to do the task unaided in the future. Mentoring is a hard job, requiring a lot of patience and an understanding of "people issues." This paper presents some ideas on how to face the challenges of the mentoring process. These ideas should be helpful both to the academic community and to consultants/trainers in industry. The first part of the paper presents some of the basic issues: some of the categories of obstacles to understanding that mentors must surmount. The second part presents some specific tips for object oriented design mentoring.

Mentoring in the context of education, training, and consulting

A novice practitioner may seek out a mentor to get assistance in performing an unfamiliar task. A mentor is a helpful person who has some experience in the task and who has some skills in the technology transfer process.

(For the purposes of this paper, the word mentor is being used to refer to someone who might also be called a "coach," a "tutor," or sometimes even a "consultant." Some people use the word "mentor" to mean a person who gives general advice to a young professional to assist their career development - but this paper will use the broader definition, which includes many activities that are considered "technology transfer.")

Mentoring is one of the job responsibilities for educators, trainers, and consultants. For example, an instructor (either a university instructor or a corporate trainer) is not always doing lecture-based training 100% of the time - the instructor wants the students to get some "learning by doing." The goal is "to get the students to make active use of what they know." When an instructor is acting in a mentor role, the instructor answers student questions with less detail but with more thought about what obstacles to understanding are at the root of the question.

In the process of consulting on a software project, a consultant will alternate between imparting information in a lecture-based mode and helping the software team members discover how they can use what they know on their own. The consultant who jumps in and performs one or more of the development tasks without engaging the involvement of the rest of the team is acting as "an extra pair of hands" instead of acting as a mentor.

A mentor can be the catalyst for getting others to turn theory into practice. This means that a novice practitioner should start with some knowledge before seeking a mentor - knowledge gained by reading tutorial material, looking at examples, and even taking some formal training.

When is a mentor's help usually sought?

It is easy to overlook the complex and varied needs of people who seek help in the course of learning a new technology. People seek the assistance of a mentor for multiple reasons:

These are all valid reasons to seek some help. In both an academic environment and an industrial environment, a request for help in any of these areas isn't shirking the job - it is almost always an honest attempt to try to acquire the skills necessary to do the job.

These kinds of problems are not always addressed directly by conventional training. In good technical training, of course, there are attempts to address the problems of applying theoretical knowledge in a practical application. But there may be a gap between the examples and exercises in training (which are usually "toy" examples) and problems in the real world.

In a well-designed training course, some of the information transfer is through mentoring rather than through direct lecture and reading by the students.

How does a mentor approach these problems?

Each of these kinds of "requests for assistance" will call on different skills and techniques from a mentor. A mentor will be more effective if the assistance that he or she supplies is matched to the state of the recipient.

Confusion: "Completely lost" is an interesting state. It is often a lack of comprehension, which is a problem that a mentor can't solve. A good mentor can ask a few probing questions - if the problem is a lack of basic background knowledge, the only thing to suggest is more tutorial materials and training courses. A mentor ought to suggest appropriate tutorials and courses - a mentor can help focus the selection of things to read and study in order to address gaps in knowledge and understanding of the basics.

Another approach a mentor can try: the "activating prior knowledge" approach. The mentor might ask questions like "how would you start to solve this problem using techniques that you learned before?" In an object-oriented design mentoring session, the mentor might guide the transformation a "flowchart" view of a single complex function into a set of services for one or two classes in a class diagram or in CRC cards.

Insecurity: Sometimes, a lack of confidence is a big hurdle. There is "lack of progress" in the early stages of solving a problem. When using an unfamiliar technology, such as a new modeling technique or tool, a person is often not sure that they are really going to get to an adequate solution to their problem with this technology. The novice will find small problems with each design diagram that they produce and they will put more and more effort into the work products of the early steps.

A mentor can help reduce the cycling - to break out of the iterative repair cycle by declaring a work product to be "good enough" to work from for the rest of the process. A mentor might also suggest working on a small subset of the original problem (or a simplified alternative problem) that will be easier to work from beginning to end.

Trouble mapping examples to practice: A mentor can often make the mapping process easier by creating extra examples - examples that are closer to the actual problem. A mentor can use samples of the work products created by the mentee to help figure out what kind of mental model has been created by the mentee, and to find gaps or misunderstandings.

Lack of experience in evaluating technology alternatives: The higher-order "evaluative" skills are always the last to develop in the process of working in any new domain. The most common techniques employed by mentors when assisting technology newcomers are checklists and review meetings.

A checklist is a low-technology way to explain a lot of the steps in an evaluation process. Examples in the object oriented technology domain include: checklists of required features for design tools, coding rules and guidelines, and design heuristics. It isn't a complete replacement for expert judgement based on experience, but it is often the best way to start a newcomer in making decisions. A good checklist will contain explanations and rationale for each item.

A review meeting is a small meeting where a group of participants (including a mentor) review and evaluate a solution together. A review meeting is more time consuming, both for the mentor and the participants, but it facilitates "learning by doing." The participants are able to go beyond using a simple checklist for evaluation, to try to explain some of their reasons for preferring one solution to another, and to have their logic checked by an expert.

Some advice from experts on training, consulting, and mentoring

Most educators, trainers, and consultants need to have some skills in doing mentoring as part of their job. Many experts have some good advice about the nature of mentoring and consulting relationships and the kinds of technology transfer problems that mentors face.

Luke Hohmann [3] notes that a mentor is used to provide supplementary experience for a software team. The mentor helps prevent small mistakes from growing into large problems. The team will gain experience through apprenticeship learning. The role of the mentor is to guide the team in learning the necessary skills.

Peter Block [1] points out that the most effective consulting processes are "collaborative." The wrong model for long-term success is to hire a consultant who performs the difficult tasks alone and leaves, because the solution will ultimately fall apart with no local ownership. In the mentoring model of a consulting engagement, the bulk of the tasks are performed under the guidance of the consultant, rather than by the consultant alone.

Elaine Weiss [7] states that effective training will help make the students capable of helping themselves after the course is over. She insists that "telling isn't training" - it is necessary to incorporate hands-on experience into a training course in order to help the students build an adequate mental model. She also identifies one important item to cover in any training course: training in how to use reference materials.

What is useful in object oriented design mentoring?

Good object oriented design mentors have a group of techniques that they can draw on during their advisory work. Some of the most effective techniques that work well in a mentoring environment are:

CRC cards have been shown to be a valuable technique for teaching object oriented thinking. UML class diagrams can be used later to create the design documentation that will continue to be used during the lifetime of a software development project. The CRC card processes described by Rebecca Wirfs-Brock [9] and Nancy Wilkinson [8] are a good place to start.

Teaching design heuristics helps developers learn some of the vocabulary they need to evaluate design tradeoffs. See Arthur Riel's book [6] for a good start on some standard heuristics. Design heuristics are a good supplement to design patterns training.

Alistair Cockburn [2] has some advice for deploying mentors when doing development with a team with varying levels of experience. His "Day Care" pattern (also called "Progress Team/Training Team") suggests creating a novice subteam and an experienced subteam. The novice subteam receives extensive mentoring in parallel with the main development effort of the experienced subteam. The novice subteam will actually be assigned important parts of the design, although their part may be smaller and their progress in achieving results may be slower. But by working a significant part of the real system, the novices will learn more than in some class exercises.

Design reviews and code reviews are for more than finding mistakes. They are a good way to introduce a team to many ideas about design tactics. It has already been pointed out that review meetings are useful for getting novice practitioners some experience in evaluating good and bad designs. It is important as a mentor to get the team into the habit of doing design reviews - not just because the review is one item on the "process checklist" but because it improves group communication. The best reviews are short (under 90 minutes), small (no more than 5 participants), and are non-judgemental.

The concept of a wrapper class is useful to introduce in design mentoring. It helps designers discover opportunities for code reuse. Wrapper classes that wrap existing non-OO packages allow object oriented design work to leverage existing legacy software [5]. Wrappers can also be written to provide a simplified interface to a deep and involved object oriented design [4].

A note for managers of software development projects

The best mentors may not be the people with "consultant" in their job title. The most effective mentors are often people in your own organization, people who may seem to be ordinary software developers. Just look for the office doorways where there is a line coming out the door and carpet is getting worn out - you will often find a mentor inside.

References

[1] Peter Block, Flawless Consulting, Jossey-Bass/Pfeiffer, San Francisco, 1981, pp. 22-23.

[2] Alistair Cockburn, Surviving Object-Oriented Projects, Addison-Wesley, Reading, MA, 1998, pp. 232-235.

[3] Luke Hohmann, Journey of the Software Professional, Prentice-Hall, Upper Saddle River, NJ, 1997, pp. 74-75.

[4] John Lakos, Large-Scale C++ Software Design, Addison-Wesley, Reading, MA, 1996, p. 312.

[5] Robert Martin, Designing Object-Oriented C++ Applications Using the Booch Method, Prentice-Hall, Upper Saddle River, NJ, 1995, p. 274.

[6] Arthur J. Riel, Object-Oriented Design Heuristics, Addison-Wesley, Reading, MA, 1996.

[7] Elaine Weiss, The Accidental Trainer, Jossey-Bass, San Francisco, 1997.

[8] Nancy Wilkinson, Using CRC Cards, SIGS Books, New York, 1995.

[9] Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener, Designing Object-Oriented Software, Prentice Hall, Englewood Cliffs, NJ, 1990.


This paper was presented at the OOPSLA 2000 Educators Symposium, Oct. 16, 2000.