Introducing Patterns: - Just Do It - Martyr
[By Date]
|
Introducing Patterns: - Just Do It - Martyr
|
|
[About]
[Publications]
[Boost Wiki] [By Date] |
|
OOPSLA 2000 Submission for the Introducing Patterns Workshop Jeff Garland Jeff Garland is a software architect and independent consultant with 15 years experience in the development of large-scale software systems. Aside from being a fanatic pattern user, he has written about, discussed, and presented patterns at the Phoenix Patterns Group meetings, Objectivity Worldview Conference, and other technical gatherings. The following are some draft patterns (Just Do It and Martyr) that may fit into the Evolving a Patterns Culture Pattern Language. These patterns describe some techniques that would fit into the early phases of pattern introduction. Name: Just Do It (Lead By Example,
Incubator, Prototype) Context: You are a software developer (Early Adopter and perhaps an Evangelist want-to-be) in a small group of people highly motivated to adopt patterns (or other new technologies). You are interested in spreading the word to the bigger organization, but you don’t have enough experience to effectively evangelize. You will be unable to find a Corporate Angel because you can’t fully explain the benefits of the technology from first-hand experience. Forces:
Problem: How can you effectively utilize new technology and position yourself (and others) to spread the word? Solution: Adopt Patterns (or other technology) within your local group. For example, you might incorporate the use of design patterns into design sessions, presentations, system documentation, and code. Take time to frequently record the benefits and pitfalls of using the new technology (ideally find a way to quantify the benefit, although this is typically very difficult). You will have to spend extra time figuring out the best way to integrate the technology. For example, you might be able to add relevant pattern references to an existing design document template. This is a long term strategy which will typically require at least 6 months of effort before you have enough background to start evangelizing on a broader scale. Resulting Context: You will gain experience from the attempt to utilize the new technology. After using it first hand you will have some lessons learned, and some concrete ideas to use in a larger process of spreading the word. You might even have created the start of a framework or process that other teams can use as a prototypical example. Once in a while an idea will catch hold and grow quickly in the organization without additional effort. Known Uses: I have used this approach several times to help alter prevailing practice within software organizations. The most successful example was the introduction of an Object Oriented software interface specification practice to a project at Motorola. The System Engineering Organization was using an old interface development practice (a derivative of a hardware development technique) that did not fit well with Object Oriented development approach we were using for software development. I was involved in the development of several major system interfaces at the time and was frustrated by the process. To resolve the problem I created a document called a Programmer Interface Guide (PIG for short – a catchy title really helps) and documented several interfaces using the PIG template. Developers outside my group immediately saw the benefit of this approach. A process was written to augment the document, support tools were developed, and the concept was adopted by the entire organization. Without a concrete example, built internally, this infusion of Object Oriented programming practice would not have been adopted. Related Patterns: This is an approach that might be used by an Evangelist want-to-be or an Early Adopter (maybe it should be folded into those). Author: Jeff Garland *********************************************************************** Name: Martyr (Revolution, It’s Easier to Ask Forgiveness than Permission)Context: You are a software developer (probably an Evangelist) in an organization that is has a group of people highly motivated to adopt new technologies, but one or more powerful managers are perceived to be against the adoption of this technology. Forces:
Problem: How can you get the blocking managers to change their mind? Solution: You make the decision to “risk it all” and attempt to gain permission by confronting the blocking managers with the need for new technology adoption. You organize either a presentation, small stump speech, or simply write an email outlining the reasons the group would like to use Patterns. You will likely need to be persistent and probably need to utilize both email and public confrontation with the blocking manager(s). For example, in a status meeting you might make the point that if the organization had more knowledge of patterns a particular problem might have been avoided since a better solution would likely have been chosen. Ideally, the blocking manager(s) will confront you publicly and in writing. You can use these public denials to garner additional grass roots support since people don’t like to be told what to do. These events may also spawn the emergence of a Corporate Angel that will remove the management barrier. Resulting Context: The manager(s) may surprise you and be willing to adopt the technology. However, if you are denied your immediate co-workers will gain respect for you due to your willingness to sacrifice raises and advancement to further the cause. As a result, Grass Roots support for the cause will grow stronger and the manager(s) position will grow weaker. There is an extremely high probability of personal career damage (at least within your current company). However, the resolution of this event may determine if you really want to continue working in this organization or should find one that aligns more with your own viewpoint. Variation: It’s Easier to Ask Forgiveness than Ask
Permission A group may apply Just Do It without the knowledge of the potentially difficult managers, by simply not asking if it is ok. In particularly, if the organization allows a high degree of autonomy for individual software teams this approach will likely be preferred to the confrontational approach. In this case, since the development group has some autonomy, it can just start using the technology and avoid confrontation. Obviously, this will limit the spread of the technology, but in the face of a hostile management team it may be the best option. It is important in this situation to be able to explain the advantages the team is deriving in case the hostile managers become aware and question the strategy. After some time, or when the managers discover that a group is using the technology, this will be the time when a team can make the case for broader adoption. Known Uses: The author utilized this technique to obtain backing and funding for a new set of Configuration Management tools. I became a martyr after I had several public confrontations and wrote a confrontational email to the blocking manager. The email used a caustic analogy suggesting that if the software team were in the tree logging business, that the manager had effectively recruited a set of world-class loggers (software developers) and outfitted them with handsaws (inadequate configuration management tools). The manager replied by denying the request and suggested that I should “fall in line” with the methods of the organization. Hanging his reply outside my office led to a new team rallying point that created more support for cause (not to mention plenty of lumber jack jokes and toy handsaws hanging from the ceiling). Eventually, the manager caved-in and appropriated money for the software configuration tool. Related Patterns: Author: Jeff Garland |