Software development organizations today are probably more aware of the value of having an effective process in place than ever before. When I say effective, I mean a process that helps the organization achieve its goals by helping manage risk, change, schedule, quality, and all of the other things that contribute to software development project success. This month we consider how to implement such a process in your organization.
However, we'll approach the problem indirectly. That is, instead of considering those positive behaviors that help improve process, we'll look at some actions that may seem likely to improve our lot, yet actually cause things to get worse. These negative actions are usually classified under the heading of anti-patterns.
Patterns are part of the software professional's toolbox today. Specifically, we learn about design patterns -- ways of designing our programs to make them more robust, flexible, and correct. Erich Gamma laid the foundation for software design patterns with his PhD dissertation in the early '90s. Gamma got much of his inspiration from Christopher Alexander, an architect who explored the idea of patterns in the discipline of architecture (not software architecture). Patterns exploded into the software development discipline with the publication of Design Patterns in 1995.1
A pattern is simply a proven approach to solving a commonly occurring problem. The pattern isn't a concrete solution that you simply cut and paste, but it is an approach to how you might solve the problem. A pattern is not the same as a template where you fill in the blanks.
Patterns are not invented. You don't encounter a problem and sit down to specifically invent a new pattern to help you solve the problem. The fact that we think of patterns as reusable elements should alert us to the fact that we discover patterns rather than invent them. While we might often think that we are going to write a reusable software component, the fact is that reuse implies use in the first place. So until someone uses our component, and then someone reuses it, we really don't know if we've done a good job of creating something reusable. The same is true for patterns. There is a simple rule of thumb that I tell my students: Once is an event, twice is a coincidence, three times is an opportunity to think about whether you have discovered a pattern.
Patterns became popular because they let software developers speak a common language. They use terms like "adapter" and "facade" the same way that woodworkers use "dovetail joint." The language enriches our vocabulary with words that carry a tremendous amount of semantic meaning. Once design patterns caught on, patterns began to appear in other areas of software development like process, requirements analysis, and so on. Each area of specialization wanted to get in on this new way of looking at the world. Patterns were the "next big thing" of the '90s. There are now books and articles on patterns for process, requirements management, software architecture, testing, project management, and so on. Practitioners and theorists tend to take a good idea and try to fit it to everything we do. I just loved my object-oriented pen in the mid '80s. I simply said pen.write and it magically did its job. 2
This rush to find patterns has, in my opinion, led to a classic situation: We can't see the forest because the trees are in the way. Suddenly everything is a pattern, from having a coding standard to holding code reviews and selecting a programming language. Applying patterns requires thought, understanding the problems, judgment about the consequences of using the pattern, and experience.
One consequence of discovering and applying patterns has been that patterns, like drugs, can be misused. In other words, we can prescribe the application of a given pattern and find, to our chagrin, that the patient (in our case, a software development organization) becomes sicker, and may even die. When we observe these effects, we have discovered an anti-pattern. An anti-pattern emerges when a seemingly appropriate approach to solving a problem in actuality makes the problem worse. I think one of the first anti-patterns was described by Fred Brooks, who observed that adding more people to a project that is behind schedule causes it to fall further behind.3
In previous articles I have described some things I think are important to consider when implementing a process for your organization and team.4 But here I'm going to present some anti-patterns to watch out for when you consider adjusting your group's process.
Describing process anti-patterns
Anti-patterns, like patterns, have certain forms used to describe them. And, like patterns, there is no universally agreed upon way of describing them. For our purposes, we will use the following format to describe the process anti-patterns I've identified:
- Name. The name provides a short, descriptive label for the anti-pattern.
- Context. Describes the problem you are trying to solve.
- Forces. The forces describe those things, in the organizational context, that cause you to consider the problem in terms of its benefits and disadvantages and lead you toward an approach to solving the problem.
- Solution. This is the crux of the anti-pattern. After considering the forces, you choose this approach. You do this because it seems logical, just as Brooks' example of adding people to late projects does. Experience, however, shows us that the solution actually leads to more problems.
- Consequences. Describes the negative effects of using the chosen pattern.
- Alternate solution. This is an alternate solution you might consider to avoid the negative consequences.
The form I have chosen to represent the anti-pattern description is not unique. I have tried to copy most of the ideas from Organizational Patterns of Agile Software Development by Coplien and Harrison. I recommend this book to anyone who wants to learn how to improve a software development organization's effectiveness.
I also want to be clear that my list of anti-patterns has not been empirically verified. The patterns reflect my personal observations from organizations and projects that I have participated in, observed, or studied. From an academic viewpoint, these are simply starting points for a more rigorous investigation. Coplien and Harrison have done their homework and conducted in-depth studies for the patterns they present in their book. I am not suggesting that this article is at the same level of confidence as theirs. I do, however, think that you will find some examples that resonate with your experience and lead you to thoughtful consideration.
Now, onto the anti-patterns...
| Name: | Take all the medicine at once |
|---|---|
| Context: | Process, like medicine is good for you. It helps bring order and health to an organization and makes things flow smoothly. At some point, an organization decides that they need to improve the way they produce software and decide to improve their process. |
| Forces: | Process is important today. We have to be able to survive audits and regulatory compliance. We need to be as efficient as possible. There are many companies, consultants, and books available to help us transition from our ad hoc way of existence to our emergence as a lean, mean software development machine that will be the envy of our industry. Management has bought the idea of process improvement and has given us the full-speed-ahead orders. |
| Solution: | We decide to implement a complete Software Development Life Cycle (SDLC) process throughout our organization. We prepare training materials, hire the best consultants and support that money can buy, and set the date for unveiling the process. From now on, everyone will do things in a consistent, predictable way that can be measured and continually refined. |
| Consequences: | Unfortunately, when we take this approach things don't get better, they get worse. Change, especially positive change, takes time. Individuals and organizations are able to take small doses of change without it causing major disruptions. Yet, we want to believe that drinking the whole bottle of process medicine will cure all of our ills immediately. The only thing it does is make the teams and their members spend unacceptable amounts of time and effort trying to follow the process and little or no time actually solving the problems they are assigned to. Eventually, they give up trying to make the process work and (or) trying to build software. |
| Alternative: | Take process in small doses. Identify key areas where you believe process improvement can provide the most help. Implement them, evaluate the results, and then prepare for the next small increment. If you collect good data on whether and how the changes work, everyone understands the benefits and is willing to accept the next change. |
I'm always amazed at how often this anti-pattern shows up. It has always seemed like common sense to me to make changes incrementally. In the last decade, though, I've seen so many organizations try to make wholesale changes to the way they do things. And it doesn't matter what process they're trying to implement. I've observed this same phenomenon with organizations trying to use the Rational Unified Process ®, or RUP®, the Software Engineering Institute's Capability Maturity Model (CMM), and agile processes like eXtreme Programming (XP). We want to believe that the best way to adopt a new process is to just stop doing things the ways we have been doing them and jump into the new way of doing things. Too often we throw away valuable ways of doing things in our organization because they're simply not defined in the new, better, more modern process.
| Name: | Bring in outside experts |
|---|---|
| Context: | When we make a change to new ways of doing things, we want to make sure that we get it right. We can't waste time trying things only to find out we did it wrong, so we hire expert consultants to come in and jump-start the new process. |
| Forces: | Time is money and with the deadlines we face, we can afford time less than we can afford monetary costs. Additionally, the experts have been through this and know what to expect and how to steer us through the dangerous currents of change so we don't crash on the rocks or run aground in shallow waters. Hiring consultants has become a way of life in the corporate world today, so it's something we can justify to our managers. |
| Solution: | Hire the expert consultant and make her responsible for the installation of the new methods. |
| Consequences: | This solution may be successful, but the chances are good that it won't be. Even if it is successful, it probably won't have permanent effects on the organization. You have, in effect, abdicated your responsibilities and given control of your team to the consultant. Your team members may perform better as long as the expert is there to keep things going, but when the expert leaves, things revert back to the way they were. |
| Alternative: | Hire an expert mentor who will help your team members develop the knowledge base and self-sufficiency to implement the process changes themselves. |
There is a Chinese proverb: "Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime." The same type of logic can be applied to process improvement. Tell someone how to do things better and she will do it as long as you're looking. Teach her to reason well and decide what changes will help and she'll take ownership of the changes and make them her own.
Kent Beck once said that software development is simply listening, testing, coding, and designing, and that anyone who tells you different is trying to sell you something. While I might not agree that his set of software development activities is complete, I do think there is wisdom in the statement. Consultants are in business, and they are selling something -- themselves. The more you sell, the more you make, so if they can make themselves indispensable, they sell more and make more. That's one way of looking at things. I believe that the really good process and methodology consultants are the ones who want to help you and your organization learn and internalize the knowledge they have and help you succeed with it. They're happy to walk away from a successful engagement where you have become self-sufficient. These consultants work with you, not just for you.
| Name: | Schedule the process implementation |
|---|---|
| Context: | Implementing a new process, even if you are doing it incrementally, takes time. You have to schedule time for your team members to learn the new methods and become competent using them. |
| Forces: | Nothing is free. Things take time. Whenever you take on any significant task, you make a schedule for it. You allocate time in the rest of your schedule for completing the task. Why should adopting a new process be any different from other tasks your team needs to accomplish? Add time in the schedule for implementing the process. |
| Solution: | Schedule a fixed amount of time for process implementation. |
| Consequences: | Process implementation shares many things in common with software development. Both require human effort and time. Both are also susceptible to unplanned changes. When learning and training are part of the task, people respond differently. There are different styles of learning and each person takes a different amount of time to learn something, depending upon their learning style and natural ability to learn. Teams have the same characteristics. Each team will adapt to new information at a different pace. When you schedule a fixed amount of time to learn the new process, there will be some things that will not be learned and they might be important for the success of the projects the team works on. |
| Alternative: | Make process implementation a separate project. Allow teams to learn the new process iteratively and incrementally. Manage the scope of the implementation just as you would any other project. |
During my years as the "RUP curmudgeon," I had the opportunity to visit and observe many customers. One of the most memorable was a visit to the Volvo facility in Gotteborg Sweden. Boris Karlsson and his staff were responsible for process improvement in the software engineering group. Boris' team attended to process implementation the way they did software projects. They gathered requirements, planned the activities needed to get the developers to understand how to use the new process, and then ran pilot projects for the various development teams. They developed just-in-time training modules and workshops and mentored the teams. This was one of the most successful rollouts of RUP that I have seen.6
| Name: | Collective ownership |
| Context: | In order to get the team members behind the new process, everyone is given "ownership" of the process. |
| Forces: | People respond better to change if they have input and some control over the change. By letting the individual team members take ownership of process implementation, you gain their buy-in and willingness to accept and work through the disruption that naturally occurs during the introduction of new methods. Organizations want to include the employees in decision making. Since process adoption is important, team members are given the ability -- sometimes the responsibility -- for defining the specific process and implementation plan. Employee participation works. There are numerous examples in companies that describe the success of participatory management, such as quality circles. |
| Solution: | The team members define and agree on the process and how it will be introduced before the process rollout starts. |
| Consequences: | There are usually two negative consequences from this approach. First, the new process may never be launched. People think they have the ability to veto anything they don't like and tend to use this to disrupt meetings and other gatherings where real progress might be made. In effect, they kill the initiative much like lawmakers kill legislation by keeping it in committee. Second, if process changes are introduced, they are a combination of favorite techniques that simply don't work together and are worse than any process that might be in place before the changes were introduced. |
| Alternative: | A small group determines the specific process changes. This group then meets with the team members to present the process and gather their feedback and incorporate changes that make sense before launching the changes. |
The important thing is to give everyone a chance to contribute their ideas and know that they have been heard. The most effective way of implementing change is to clearly describe the change, why it is necessary, and the benefits you expect. Then you have to let the people speak. They are the ones who will be affected by the change. It turns out that they often will have suggestions that will make the change more effective or they will point out problems that you might not have thought of. You must be able to acknowledge that they have good ideas and not be afraid to change your viewpoint in the face of good ideas. If you aren't flexible in your thinking, you shouldn't be implementing process change -- there is no room for ego here.
| Name: | Small increments, short iterations |
|---|---|
| Context: | You decide to fashion your process improvement project after a software development project: iterative and incremental. Software projects seem to be done best when the increments are small and the iterations are made as short as possible. |
| Forces: | You need improvement and are under pressure to change as quickly as possible. We think that making the increments small will let us introduce them rapidly. As soon as we finish the deployment of one change we start introducing the next one. People learn one thing at a time and it seems reasonable that this approach will actually shorten the overall duration for process change and we will be able to reap the benefits of changes as soon as they are implemented. The net effect should be cumulative. |
| Solution: | You set up deployment teams, training materials, and training sessions for each change and schedule them so that there is just a short interval between each wave or iteration that introduces a new method. |
| Consequences: | This approach leads to confusion. Just because you have been taught something doesn't mean that you understand it and can use it. People take different lengths of time to become even partly competent with new methods. Simply throwing new changes at them in rapid succession actually lengthens the time it takes for change to occur, and may even cause the overall process improvement to fail miserably. |
| Alternative: | Identify small sets of changes that address a specific area of the organization or process. For example, train people how to apply use cases for their requirements analysis, system design, and testing. Train the people, with refresher classes along the way. Let them use the new techniques on a complete project. Then introduce the next set of methods and changes. Things take time. Unless you allow people to digest the new methods, use them, adapt them to their particular projects, and finally internalize their use, you have little chance of them actually being able to succeed with them. This is a case where haste truly makes waste. |
These few anti-patterns give you a taste for what can go wrong if you apply good ideas the wrong way. You can probably think of many more. I would urge you to read Organizational Patterns of Agile Software Development and try to think of anti-patterns for the patterns presented. If nothing else, it will get you to think more deeply about the patterns themselves. We will explore some more anti-patterns that apply to people, process, and tools in future columns.
1 Design Patterns: Elements of Reusable Object-Oriented Software, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Addison-Wesley, 1995, ISBN 0201633612. This is commonly referred to as the Gang of Four, or GoF book.
2 I hope the humor emerges here. The point I'm trying to make is that our nature is to take things to the extreme.
3 Brooks stated this in his classic book, The Mythical Man Month: Essays on Software Engineering. This was originally published in 1975 and re-published in a 20th anniversary edition in 1995.
4 See Does process matter?, Aug. 2006, http://www.ibm.com/developerworks/rational/library/aug06/pollice/index.html and Matching project and process, May 2004, http://www.ibm.com/developerworks/rational/library/4720.html.
5 Organizational Patterns of Agile Software Development, James O. Coplien and Neil B. Harrison, 2005, Prentice Hall, ISBN 0131467409. Don't be fooled by the title. The authors admit in the preface that they included "Agile" for marketing purposes.
6 Boris and his colleagues presented their results at a Rational Users' Conference. They also published a white paper about their approach. You can read it at: http://www.taika.com/techlib/files/implementing-rup-in-volvo.pdf.
Gary Pollice is a professor of practice at Worcester Polytechnic Institute, in Worcester, MA. He teaches software engineering, design, testing, and other computer science courses, and also directs student projects. Before entering the academic world, he spent more than thirty-five years developing various kinds of software, from business applications to compilers and tools. His last industry job was with IBM Rational software, where he was known as "the RUP Curmudgeon" and was also a member of the original Rational Suite team. He is the primary author of Software Development for Small Teams: A RUP-Centric Approach, published by Addison-Wesley in 2004. He holds a BA in mathematics and an MS in computer science.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
