Growing Your Own

If you plan to scale a face of Mount Kilimanjaro or Mount Everest, you certainly would want a well-trained team and some experts to guide your climb. This section helps you take those raw recruits you just selected and turn them into a well-prepared team.

The Training Trap

As you begin to take these first steps, though, don't fall into the training trap. We all get those glossy magazine-like advertisements from training companies that list dozens of classes you can take. I surveyed a few recently. Overall, about 85–90 percent of the courses listed were for programming languages. The promise is that you'll take the one-week course, and then you'll return to your cubicle and be able to start coding in the new programming language the next week. This promise is the bait in the trap. This might work for programming languages, but not for understanding how to perform analysis and design with the UML. (By way of analogy, building a bridge is different from designing the bridge, requiring different skills and tools.) A programming language might be object-oriented, but learning an object-oriented language does not mean you will learn the concepts for good object-oriented design using the UML. However, the industry has expected that training outcome for so long (based on programming-language course results) that they expect it for UML and object-oriented training courses, too.

From the Real World—Trapped! I visited a company for a day-long series of job interviews. A bit past midday, I entered the office of the Vice President of Development. After exchanging pleasantries, we sat down, and she gave me a very odd look, though I thought it was just my imagination at first. I had been interviewing all day without a break, not stopping for lunch, and my energy level was flagging. Then she snapped at me, “So you're the object-oriented expert. I just sent my people to a C++ class. They came back and now they can't do this OO stuff. You tell me why.” I thought to myself, “Whoa! I wasn't the trainer. How would I know?” She had fallen into “the training trap.” I explained to her that she had misplaced her expectations. C++ is a programming language. Language classes don't typically teach you how to do good object-oriented analysis and design (OOAD)—no more than learning the English language will enable you to write “The Great American Novel.” She hadn't sent them to an OOAD class or a UML class. But the industry is used to sending people to a programming language class for a week and then back to work to begin coding in that language, which is the wrong expectation for UML and OOAD. If you go to a UML class, you might be able to learn the UML basics in a week. However, you need more if you want people who can do OOAD well (more on this later in this chapter). Plus, you need to ensure that real practitioners are providing the training, not just people who pitch canned training slides. Her scowl didn't change. I finished the interview gauntlet later that day. And yes, I got the job.

Lessons Learned Understanding an object-oriented programming language does not mean you understand the UML. Understanding an object-oriented programming language does not mean you understand object-oriented analysis and design. Expect the unexpected during interviews.

Mentors

UML training classes can only take you so far. You also need training in OOAD. But even this only provides you with a foundation upon which to build your knowledge of the UML. To really develop the skills to perform excellent OOAD with UML, you need more. You need mentors to help guide your people through the intricacies. When starting out, you might have to hire mentors from outside your company. There are many consultancies where you can find such people. Make sure part of their job is to create in-house mentors for the future. In that way, you can seed new projects with your own in-house mentors. Then these internal people will groom additional mentors, and so forth. By repeating this process, you will develop internal expertise on UML and OO for your future projects and can reduce your dependency on external experts.

Apprenticeships

An activity closely related to mentoring is apprenticeship. Your external or internal mentor is not responsible only for helping train your up and coming UML specialists. Your newly minted UML/OO folks should not be thrown onto a real project alone—they should apprentice on a project with an experienced mentor. Projects in the real world have much more complex issues than you will ever see even in the best training regime. Training problems are structured and controlled in order to teach specific concepts and provide safe, no-risk learning. Not so on real projects.

Apprenticing will help your folks through the “Blank Sheet of Paper Syndrome” from which even your best newly trained OO folks are likely to suffer. This syndrome occurs when they are assigned to a new project and begin the task of modeling the system with that big, blank sheet of paper (or blank computer screen). Thoughts such as, “Where do I start?,” or “This isn't like what we learned in class,” or “What should I do?” immediately pop up. In the best case, this mentally paralysis doesn't last too long. In the worst case, these neophytes might start down the wrong path, and all their subsequent work can be for naught. You will also find that most people don't get over this syndrome until their third new OO project or so.