Sam watched the vein pulsing in Jim's red face and realized that this meeting was not likely to go well. Jim was usually one of the calmest, most easygoing members of her team. Right now, he was as angry as she had ever seen him. 

 
"Sam, you have to do something about Bob! He renamed all of the methods in the accounts receivable module. Now none of the other modules will link to it!" 

 
This was just the latest in a series of similar problems with Bob. He was one of the most talented programmers Sam had ever met. His knowledge of the operating system and the tools used to create systems was encyclopedic. He had the highest productivity of anyone in the department. He had just one tiny flaw. 

 
"He's like a dog marking his territory! He doesn't like code written by somebody else until he's changed it to the way he likes."  

 
Sam thought that this was an accurate description. Bob had been with the company for several years. During that time, there had been a series of similar incidents, about one every six months. There was the time he changed the design of a key module when they were halfway through system test. Granted, it had made the module much more efficient, but it had invalidated all of the testing that they had already done. Testing had to stop for several days while the changes were unwound and the system rebuilt.  

 
In contrast to the problems were the miracles that Bob regularly produced. He had improved the performance of a critical module by a factor of a thousand, fixing a disastrous throughput issue. He produced tens of thousands of lines of code. While others might complain that the code was difficult to understand, Sam knew that it was truly elegant in its design. Bob also had one of the lowest defect densities in the department. 

 
Sam calmed Jim down and promised she would talk to Bob. Sam dreaded these meetings. Bob was well aware of how good he was, and it was always a struggle to convince him that the rules should apply to him as well. These meetings could last hours and leave her feeling drained. Bob would sulk for a while, but he would improve. During the years he had been with the company, he had really progressed. It had been at least a year since anyone had demanded transfer off one of his projects! 

 
It was difficult to predict how Bob would react to another one of these meetings. Once, Sam had called him on the carpet for making unauthorized changes to the system. She had explained to him that he should only work on issues assigned to him. So, Bob had gone into the issue tracking system, entered a bunch of issues concerning code that he didn't like, assigned them to himself, and fixed them. 
Sam made an appointment with Bob for the next morning. 

 
"Bob, Jim is very upset. He said you renamed all of the methods in the accounts receivable module. Because of the other changes you were making, he will have to back this out by hand." 

 
Bob began to get agitated. "I was fixing the bugs. While I was in the code, I updated it so it conforms to our standard." 

 
"Bob, we've talked about this before. The decision to update code to the standard is supposed to be a joint one between the project lead and the supervisor. I can understand why you wanted to do it, but this code is some of the oldest in the product and is used by many different projects. What you did makes it more difficult to share code between projects." 

 
"Give me a week, and I'll update the rest of the code," Bob insisted. 

 
"Bob, you might be able to do the edits in a week, but it would take us three months to requalify the code. We don't have the time or the budget to do this." 

"I can get it done. Don't you trust me?" 

 
"It isn't a matter of trust. Our development process requires us to requalify every changed line of code." 

 
"I can understand why you need these processes for the rest of the group, but they just don't make sense for me. You know how low my defect density is." 

 
Sam sighed. "Bob, I can't have one set of rules for you and another for the rest of the department." 

 
Bob stood up. "You're holding me back. You aren't giving me the authority to make the changes that need to be made. I can't work like this." 

 
"Bob, I can't keep having these incidents, either. You need to follow the rules." 

 
"This is ridiculous. I've talked it over with my wife, and I've decided to quit." And he walked out of the office. 

 
Author's Note:

 
Modern software development is a team effort. Superstar programmers can be more trouble than they are worth if they refuse to be part of the team. The benefits of their extraordinary productivity are often outweighed by their effect on team morale and by their additional burden on management. If you have a prima donna on your team: 

• Set boundaries and stick to them. 
  
• Look for work where he can be a solo performer.  
  
• Be extra vigilant. Keep a doubly close eye on what he is doing. For example, do "before and after" inspections of his work products.  
  
• Know when to cut your losses. If bad behavior isn't changing, encourage him to seek his fortune elsewhere.