Last month I offered some anti-patterns for process adoption.1 This month I'll continue to look at anti-patterns, but I'll focus on 1) people and 2) tool adoption, the other two key ingredients for successful software development.
Let me quickly restate what I mean by "anti-pattern." Last month I described an anti-pattern as "a seemingly appropriate approach to solving a problem that, in actuality, causes the problem to become worse." Keeping this in mind, let's jump right into looking at ways of managing people and handling tool adoption that seem to make sense, but in reality can mean disaster for our projects and organization.
Software development is not just a technical discipline. In fact, one might argue that it is mainly not a technical effort, but a team effort that involves individuals working smoothly together. Good managers are able to achieve and nurture cooperation and collaboration among team members, resulting in the production of great software systems. Over the last five years -- given the rising popularity of agile development, along with rapid growth in the tools sector of capabilities for collaboration (consider the SourceForge community, for example) -- more emphasis has been placed on teamwork in software development than ever before. With the emergence of more globally distributed development, collaboration among the people on development teams has become a critical factor for success.
I'll start the list of "people" anti-patterns with one of my favorites. As with the anti-patterns presented last month, these are based upon my personal observation over the last four decades.
| Name: | People are resources -- treat them that way |
|---|---|
| Context: | People are the key element for success in software projects. We work in a knowledge-based industry where the people are the repositories of the knowledge. We hire good people for the skills they bring to the job. This allows us to assign them to projects somewhat interchangeably. |
| Forces: | If we can consider people to be like other resources, we can manage them the same way. It gives the manager more flexibility and the organization the capability to meet the constant changes regularly encountered in software development. In this way, budgeting and work capacity should become more predictable. |
| Solution: | People are identified by their skill sets rather than by their individuality. The typical structure that indicates this type of organization is the matrix organization. We simply have so many units of programming talent, so many of testing talent, and so on. People move from project to project as the need for their skills arises. |
| Consequences: | There are two consequences to moving knowledge workers of any type from one project to another, wherever their skills are needed. First, employees rarely gain any sense of ownership, which is important to most software developers. They like to be able to point to their accomplishments with pride and talk about their contribution to the final product. Second, they are denied that sense of belonging to a team, and teamwork is fundamental to software development best practices. Individuals working in relative isolation, moving from one project to the next as their skills are needed, will rarely sustain their excitement for developing great software. |
Most of the matrix software development organizations I've encountered have usually been in IT shops, especially in large companies. Companies that build software products seem to organize more around teams.
One characteristic I have observed over the years in all great software developers is their passion for their work. Their sense of accomplishment and intellectual growth is the most important reward they get from their job. When they become interchangeable cogs in a large machine, they lose this and their work becomes just a job. They either leave that job, seeking bigger challenges where they will regain their passion, or they become contributors who do what they are told to do, and nothing more. In either case, the organization loses tremendous potential.
Chris Lowe, one of my colleagues a few years ago, made an observation that I continually think about. He basically said, "When they changed the name of personnel to human resources, things started going downhill." Simply put, when we treat people as human resources, we begin to dehumanize the job. I think that is a tragedy of modern business.
| Name: | Reward often |
|---|---|
| Context: | Geeks are different! They are happiest when they can work hard and play hard. Although many of the best don't particularly like the "usual" social rewards that other employees might value, they do like recognition and reward that adds to their status and lets them know that their work is highly valued. If you've been around software developers for a while, you might notice the pride they take in their T-shirt collections, gadget collections from various conferences they attend, and other things that give them identity and status. |
| Forces: | Small gestures are often as well-received as large ones, so providing frequent smaller rewards can be an effective way of keeping your technical employees happy. |
| Solution: | Find small, relatively inexpensive rewards, and bestow them upon the developers often. |
| Consequences: | Unfortunately familiarity breeds contempt. Today's reward is tomorrow's expectation. Rewards that are too frequent and handed out like penny candy quickly lose their value. While it's true that rewards don't have to be expensive, they must be awarded at the right time to the right people. |
I'm sure that every reader can think of rewards that have lost their effectiveness due to their having become a commonplace occurrence within an organization. I can think of several examples in my career where this has happened. Many of them seem to involve food as the reward. I have been at several organizations where the company offered the team free lunches, possibly free dinners, free pizza, popcorn, and so on. It doesn't take long for the team to expect this as the norm and the concept of reward for doing good work is lost completely. In fact, what often occurs is that the team begins to complain about the lack of variety, lack of special foods, and more. What was meant to be a bonus for the team becomes a point of contention between the team and the company. The team starts to look at the reward as not meeting their needs and translates that to the company not caring about them.
Similar effects can be seen when you have regular rewards given for employees meeting their responsibilities, but not going above and beyond -- that is, they do their job, do it well, but have not done something truly outstanding. Those stock options, or T-shirts, or jackets, and so on can actually be a demotivator in the long run.
There is an analogy to this problem in the academic world -- grade inflation. I find that I have a difficult time convincing my students that a grade of B is a good grade. They believe that if they do good work, not necessarily outstanding, they should get an A. Not in my class.
| Name: | Consistent rewards |
|---|---|
| Context: | You want to reward your employees and you want to make sure that the rewards are consistent. Employees need to be rewarded in a manner that is consistent and does not favor one employee over the other. |
| Forces: | There are many constraints placed upon employees at all levels regarding what they can and can't do. We need to be careful that favoritism is not practiced. |
| Solution: | We create generic awards that are regulated by company policy. We apply these rewards consistently in order to ensure fair treatment of all of our employees. |
| Consequences: | As in the "reward often" anti-pattern, the rewards tend to be meaningless. They become viewed as just a simple extra that the company gives to everyone. Even if it is not given to everyone, all who do receive it receive the same thing and the opportunity for special recognition is lost to the organization. |
Every year I tell my students this story, which illustrates why rewards really ought to mean something. I once worked for a company where they gave five-year rewards for employees. There was a dollar limit placed upon the gift that the manager was expected to obtain and present to the employee. The custom was to get a gift-certificate for the allowed amount and give it to the employee. This meant that the employee could then get what he or she might really want. It was also simpler for the manager.
I had a new manager whom I had only met one time. And she was given the task of "rewarding" me for my tenure at the company. Instead of the usual gift certificate, she took the time to find out what my interests were. For my gift, I received a shakuchi -- a Japanese bamboo flute that I had been wanting to add to my instrument collection. Now, the amount of the gift was actually less than the maximum amount allowed, and it really didn't take my manager that much time to find out what I would like. But, it was something that I will always remember, something I appreciated, and it made me feel like I was appreciated.
| Name: | Maximize skill usage |
|---|---|
| Context: | Each employee has a unique set of skills that makes him or her valuable to the company. We choose project members for the skills they have and for what they can bring to the project. |
| Forces: | Specialized skills are worth a lot in the marketplace. We must strive to optimize our resource usage (see the "people are resources" anti-pattern) by ensuring that employees with certain skills are applying those certain skills all the time. |
| Solution: | Every time there is a need for a specific skill, we make sure the employees who are known for those skills are given the task. |
| Consequences: | While this solution might have short-term benefits, the long term benefits for the organization are small. What often occurs is employee boredom, or lost enthusiasm, leading at best to mediocre job performance. At worst, employees simply quit. |
Since we are in a knowledge-based business, we have to realize that knowledge is capital to the workers. Software developers pride themselves on the number of programming languages they know, the number of new technologies they have become expert in, and the new things they have learned and are learning. If we fill their time with work that requires full application of those skills, when do they learn new skills?
Many companies today require training goals for employees, which become part of their annual review. This is often in the form of course work -- both within the company or given outside of the organization -- and conferences where workers find out what's new in their areas of interest. This is only a partial solution. Taking a course or attending a conference is just the beginning of learning new technology and techniques. It takes time to learn how to apply them and become proficient with them. Trying to apply new methods to projects that have established deadlines is difficult, and often impossible. Yet, proper learning requires time to internalize the new information and experiment with it. So, just having the employees learn new skills is not enough.
Some companies try to build time into employees schedules for such learning. Some methods are better than others. One of the best I've heard of is Google's 20% time, where employees are "free to pursue projects they're passionate about. This freedom has already produced Google News, Google Suggest, AdSense for Content, and Orkut -- products which might otherwise have taken an entire start-up to launch."2
Another effective way to allow employees to truly integrate new skills into their existing ones is to provide employee sabbaticals every so often. It is well established that college professors are better able to keep abreast of the latest advances in their field and produce important research results by taking periodic sabbaticals. They go to other institutions or business organizations and work in areas that will help them extend their knowledge. I've only seen a few companies that offer sabbaticals, but I think it is a great way of encouraging employees to excel.
In concluding this section on the people anti-patterns, I recommend Joe Marasco's book, The Software Development Edge: Essays on Managing Successful Projects. Joe tackles many of the tough problems of managing software developers such as how to reward your superstars. It's definitely worth a look.
Speaking of Joe Marasco, he pointed out a recent article titled "The Gatekeeper's Guide, or How to Kill a Tool" to me.3 This article is quite humorous and points out many anti-patterns regarding tools indirectly. I won't try to formalize anti-patterns from the items in the article. I'll leave that up to you. I will, however offer a couple of additional anti-patterns that I've observed when it comes to tool adoption. Some of these go somewhat against the wisdom of the aforementioned article, but you need to consider the context and forces.
| Name: | Enforce usage on all projects |
|---|---|
| Context: | In order for tools to be effective, they must be used regularly. We can enforce the tool usage by making it part of the development process for all projects in the organization. |
| Forces: | To become proficient with new tools, the cost in terms of purchasing the licenses, then the training, then spending time with the tools is significant. If the tools are not used, the money is just wasted. Therefore, we need to find ways to ensure the tools will be used. |
| Solution: | Modify the development process and incorporate the requirement that each tool must be used on all projects. This guarantees that the team members will become familiar with the tools and use them. |
| Consequences: | The tools are used ineffectively and often in cases where they provide little or no benefit. Instead of team members taking advantage of the benefits the tools might provide when they are used properly, they are seen as an obstacle to developing good software. The team finds ways to do the minimum required by the process and never tries to use the tool as an aide. |
Software tools are designed for specific types of projects and circumstances. There are no tools that can be used successfully on every development project. Software tools are in many ways similar to woodworking tools or tools for any other craft. A skilled woodworker knows which tool to select for the job at hand. Software developers must develop the same ability. By forcing developers to use a particular tool, just because it may be the latest one or the most expensive one in the toolbox, encourages team members to avoid making a thoughtful choice based on their actual needs.
| Name: | Use all the features |
|---|---|
| Context: | Tools provide many features to help users improve their work. Each feature was, in theory, put into the tool because it has been shown to be useful. |
| Solution: | Therefore, we should use all of the features provided, or as many as possible whenever we use the tool. |
| Forces: | Since we have a tool, we should use it. In order to recoup our investment in the tool and training, it makes sense that we will recover the costs quicker if we use as much of the tool as possible. |
| Consequences: | Although there are often many features included in software tools, they are usually there because they were found useful in some cases, not because they are useful all the time. Just as we don't want to always use a tool, we don't want to use every feature whenever we use the tool. We want to use tools effectively, which means knowing what features of that tool are applicable to the current problem. If we blindly use all capabilities of a tool, we lose much of the benefits that we might otherwise gain. This loss is simply due to wasted effort on using features that are useless for the current work. |
I have worked for several tool vendors as a developer, consulting and providing professional training. I found that when an organization acquires a new tool, the people using the tool feel obligated to try to use it all. But tool adoption is like process adoption -- take it slowly and give yourself time to find out how to do it and when to do it.
There is no doubt that UML is a useful tool for communicating designs and for analyzing problems. What is not clear to me is how useful it is to try to generate code from the models, and when. There are different levels to using UML and related tools, depending on the type of problem I'm working on.
If I am building a simple language processor, I'm not sure I would use UML at all. The structure of language processors and their implementation are already well known. Using a formal grammar to specify the language is in fact the appropriate technique.
Now, if I have a moderate-sized project, I might use UML and a tool that supports UML to create enough class diagrams, sequence diagrams, and others to convey the design. When I actually put my diagrams into a persistent form using the tool will depend on other circumstances regarding how hard the diagram is to create and modify within the tool. In other words, I'm not sure I would detail these diagrams to the point where I would have sufficient detail to generate meaningful code for this project.
Imagine that on this same medium-sized project, I'm using IBM Rational ClearCase as my source code management tool. I would certainly set up ClearCase so that I could begin checking artifacts in and out and sharing them with the other members of my team. But I'm not sure I'd need to take advantage of ClearCase's parallel development capabilities, using multiple branches and so on for a project of this size.
On a large project, I would certainly want to use more features of the tools to ensure that the team collaborates more and has a more formal way of communicating. There would most likely be parts of the model where code generation is quite useful; and if the project is a lengthy one, there would likely be an opportunity to use an SCM tool's parallel development features.
I suspect, and actually hope, that most readers will look at this month's column (and last month's) and think "this is just common sense." Yet, I know that in practice, it is uncommon sense. So many software projects get into trouble because project managers try to apply formulas that just don't work. Software development is a significant part of an organization's overall IT capability, and IT is essentially a knowledge-based industry. That means we need to apply knowledge in an appropriate way to handle the three keys to success -- people, process, and tools.
1 See http://www.ibm.com/developerworks/rational/library/dec06/pollice/index.html.
2 http://www.google.com/support/jobs/bin/static.py?page=about.html.
3 Eugene Farmer, "The Gatekeeper's Guide, or How to Kill a Tool," IEEE Software, Nov/Dec 2006.
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 B.A. in mathematics and an M.S. 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
