Bill Hamilton at MTS Tech. in San Diego wrote one of the most thorough letters of recommendation that I've ever seen. It talks not only about the OO-Design training that I did for them, but also about the OO adoption process. Here's the letter in its entirety. (Write to me if you want to get in touch with Bill.)
I'm sorry I missed your call. Every other Friday is a day off for us. I'll be glad to apress your questions and any others that may come up. MTS Technologies, Inc. is under contract to Naval Health Research Center (NHRC) to provide IM/IT support for Field Medical Technologies. We provide network administration, software development, project oversight, verification and validation, field test and evaluation, and transition services to NHRC. I am the Technical Manager for MTS's Field Medical Technologies Division. I oversee several projects and 32 people. With that background, I'll try to provide the best answers I can. The following are my personal opinions and not that of MTS Technologies, Inc.
How many attendees from MTS?
I contracted with Allen for two classes. The first was OO Analysis and Design for nine of our programmers and one government programmer. The second was OO Project Management in which we had one representative from D.C. (funding sponsor), five NHRC Principal Investigator's (PI's) and three MTS Program Managers (PM's). During the course, the class divides into two smaller groups and works hands-on with a project they select (be prepared to bring one of your real world problems to class!). Our groups split into two in the same classroom and while this was convenient for Allen to keep an eye on each group, it detracted from the effectiveness. It's important that the groups get this hands-on time and it's important that they struggle through it. But, I would like to have found a way to better separate the two so they didn't distract one another.
Onsite or public?
I held both classes onsite. The government was concerned about the amount of time away from their normal duties. I also felt it was important both to have them in a comfortable environment as well as to have Allen see our facilities and understand our role to help tailor his presentation. I felt Allen easily grasped our situation and much of the class was directly applicable to our projects.
How long ago?
The OOA/D class was held the last week of April (2004) and the Project Management class was in mid-July.
Purpose of attending?
We had a diverse skill set and I wanted everyone on the various projects thinking and talking in the same language. I had individuals with almost 30-years of experience at Hewlett-Packard and individuals whose last language was PL/1. I kept some of my notes and this is what I used when recommending the class to senior management: My goals for this class are: 1) to bring a common understanding of the OOA/D process to the entire team so that those in support roles will understand what those in active OOA/D roles are doing and saying, 2) to introduce UML notation to the team as the majority are not familiar with it, 3) to set a high-standard for our OO development by bringing a "purist" in to lead the class (so many OO projects fail to deliver on the promises of OO that I want someone who knows the rules and obeys them), 4) to evaluate team members on their leadership and teamwork skills (I purposely have not set any expectation for a "leader"); I want to see if the teams "gell", who leads "naturally" and who are strong supporters, 5) to see who can "walk the talk", who is most interested in improving their skill set and if anyone is "bluffing". .
What other training classes did you consider?
I scoured the Internet and evaluated a host of other opportunities. I do not have the notes from that evaluation. I spent three months researching the various opportunities before I settled on Allen's.
Why did you choose Holub's class?
There are two distinct reasons I chose Allen's class: first, he's a purist as exemplified by his articles and second, he's a very critical thinker. I believe this is a double-edged sword for Allen. While it does distinguish him from others, it also makes him the target of a great deal of criticism. I have over 20 years experience in IT (http://www.billhamilton.com). I tell every team I've managed: you may CRITIQUE anything, but you may never CRITICIZE anyone. Allen accepts constructive criticism, but what I liked most was his ability to articulate his reasoning as to why he took a position opposing a point-of-view. Take his 'Evil of Getters-Setters' article. His position is not that of popular opinion, but he was able to articulate logical, sound reasons why his methodology made sense. His methodology was also more of an OO purist, which I can also respect. I do not believe in doing things half-way. You either do them right, or not at all. If you're going to do a project using OOA/D, then don't compromise the project by interjecting procedural habits. That was my greatest fear going-forward and one of the big motivators for bringing in an outside consultant to put everyone on the same page.
Use of OO techniques before class (at MTS or elsewhere)?
I have only been with MTS for one-year and they did not use OO techniques before I arrived. I personally have used OO techniques as situations allowed since I first read David Taylor's book back in 1995. As a consultant, I wasn't always in a position to make a difference, but wherever possible, I utilized OOA/D in my work.
How would you describe your level of expertise before class?
Not nearly the same as after! And that goes two ways: first, it was a humbling experience even for our most senior OO programmer and second, I've seen others start off their description as, 'If what I believe is correct, then I'm...'. I believe I understand OO's fundamental principals and how they're applied. I believe our team now understands that as well. However, I do anticipate bringing Allen back in at various points in our analysis and design phase to offer his critique and help us in our application. Do we do everything right? No! But we do it far better now than we did before.
How has the class affected the way you do things today?
Looking at our code now, I feel much better about how it's organized, about how it performs, and about how easy it is to maintain. I had our team complete an assessment and make recommendations (I believe team members have a say in what affects them and the right to critique my decisions, so I always involve them in key decisions and I have them evaluate my effectiveness). I'd like to share what one of my programmers, Zachary Sempers, had to say:
1) The Training
This was a good intro to OO. We started with the very high level overview, and I found the first 1.5 days - which were mostly lecture - to be a good starting place for me. As a long time programmer raised in a procedural world, OO is an area I knew very little about. I found the hands on portion of the class - the next 3.5 days - to be a great idea; having programmers actually get up and design something on the white board. It was reassuring to see that I wasn't the only experienced and capable programmer struggling with how create an object model. I think that the hands on section was brilliant.
2) The trainer
Alan obviously is very knowledgeable about all things OO. Apparently, he is deeply involved in the OO, UML and Java worlds so he can give accurate and meaningful answers. He is easy to work with. He was rather ego-less about his skills, which makes him even better to work with. He actually has teaching skills, too. All around, a good guy to teach this class.
3) What I learned
I received an overview into object modeling; OO, UML, dynamic and & static modeling. How to start thinking in terms of objects for the first time. I learned that I need to bone up on UML as well as object modeling altogether.
4) What I would have done differently
A) UML, Dynamic & Static Modeling
We were swimming around on problems for a while longer than I would have liked. This is an inherent part of the process of learning: you don't know what you don't know until you learn it. Translating our procedural thoughts into an object model using activity diagrams, class diagrams and a dynamic model was a big switch. While the following is true for me, I believe it may be true for others. Having had no background whatsoever in UML, or structured class design, I didn't know what I was supposed to use to express my thoughts on the white board in terms of an object model. It's somewhat like an English speaker taking a course in conversational Chinese or Greek. The English speaker may know that he wants to find out how to get to the bus stop, and even be able to say this 5 different ways in his native tongue, but in terms of writing it in Chinese on a white board, where to start? A straight line? A squiggly one? Up and down? Left or right? Is it a square box or an oval that goes around the word? What about these dashed lines? Darken arrow tip or hollow? And where did these half circles that point back at themselves come from? I wished I had known that I should have studied the UML guide before the class started. But I don't think we got it until the second day. Moreover, it didn't occur to me to thoroughly study that diagram until class was almost over.
The following are Mr. Sempers' recommendations:So, here's what I would recommend that Allen do differently:
i) Before the course hand out the UML guide and tell people that to get maximum value out of the class, study the UML guide unless you've already got OO. I would have done so if it was suggested. Alternatively,
ii) Have Allen be present in the class full time and not let people struggle on the issues of how to write things in UML for quite so long.
B) Translating Procedural Thinking to OO thinking Because this was a OO training class, I know that Allen was very concerned about us learning to do it ourselves - and that includes stumbling, getting emotional, and hopefully seeing what's important in the process of thinking OO and what's not. This is why he didn't write our object model for us. Because Allen had to split his time between two groups, he couldn't be there all the time. We would have made substantially more headway had he been in full time attendance with one group at a time.
Here's what I would recommend be done differently:
i) We should have either had the entire class do the object model; alternatively ii) Have three more days for him to work with us independently.
Overall, I think Allen is a very valuable person for this project and this organization. The above notwithstanding, whatever you paid him it was a bargain.
I'd like to assume that you're interested in my opinion as to whether Environmental Systems (ES) should do anything differently than MTS did assuming they go forward with Allen's class(es) (because I'm about to give it to you!). When evaluating Allen's class, you really need to evaluate what Environmental Systems wants from its development efforts:
- Is a purists' form of OO right for ES? (i.e. do you really care that getters and setters do or do not appear in your code, because they certainly haven't broken anything in most code yet, or are you comfortable enforcing the compliance upon every programmer to pass objects?). Don't accept a compromise. Make the commitment to do it right from now on, even if you feel it takes a slightly longer period of time to do something. Unless you're throwing your code away in six months, you'll be revisiting it and the payoff will become real.
- Are you comfortable with a certain amount of stress as people adapt to a more rigid way of thinking? It will take your programmers time to adjust to a purists way of thinking and sometimes they'll have to trust that it's the right thing to do ' which can lead to an anxious feeling. Some will have to give up long held beliefs and that's not easily done. They don't need to argue over whether a curly brace starts on the same line as a method or the next line below it, but they will need to determine whether to extend or implement and that is important!
- Can your team interface with a confident trainer when the two do not agree on how to implement OOA/D? There were some in our class who thought Allen was arrogant, but I (and my senior team members and those who "got it" do not. Allen does not back down. His opinions are well thought out and his arguments are sound. You can have good discussions, but not everyone has to agree. Do you have strong leadership that can implement the difficult decisions and a team that is willing to follow that leadership? Not having the above ability or team cohesion may mean that you need apitional mentoring through the first project.
One last thing you have not asked me is, would I do it again? Absolutely!