IEEE Software, Vol. 15, No. 2, March/April 1998
Dealing With Problem Programmers
"For me, programming is a head rush. Im always
working on the edge. When I put software out there, I dont know whether its
going to work. Thats part of the excitement. If its not exciting, I dont
want to do it."
"What do I do with a problem programmer?" This is the question
I hear most often in my consulting work. Stories of problem programmers abound. One
developer initially refused to follow the projects design standards in creating a
certain module. After finally being given an ultimatum, he coded the modulebut he
wrote the variable names, function names, and comments in German. Another developer
insisted that he was making steady progress and that his Microsoft Windows code was
finished; meanwhile he spent two months exploring the new Apple Newton. When the time came
to integrate his code with the rest of the teams work, none of it was done. He had
created some rough prototypes, but nothing was tested, debugged, reviewed, or even
remotely ready to be released. Another belligerent developer had apparently never heard of
egoless programming. Whenever she found a defect in another programmers work, she
would say, "OK Mr. Smarty Pants Programmer. If youre so great, how come I just
found a bug in your code? I guess maybe youre not so smart after all."
How Bad is Bad?
In addition to attitudinal differences, significant productivity
differences among programmers have been well documented. In the first study on the
subject, Sackman, Erikson, and Grant found differences of more than 20 to 1 in the time
required by different developers to debug the same problem ("Exploratory Experimental
Studies Comparing Online and Offline Programming Performance." Communications of
the ACM, January 1968). This was among a group of programmers who each had at least 7
years of professional experience.
This basic resultdemonstrating at least 10 to 1 differences in
productivityhas been reproduced numerous times, but I think it understates the real
productivity differences among practicing programmers. Tom DeMarco and Timothy Lister
conducted a coding war game in which 166 programmers were tasked to complete the same
assignment ("Programmer Performance and the Effects of the Workplace," in Proceedings
of the 8th International Conference on Software Engineering, August 1985). They found
that the different programmers exhibited differences in productivity of about 5 to 1 on
the same small project. From a problem employee point of view, the most interesting result
of the study is that 13 of the 166 programmers didnt finish the project at allthats
almost 10 percent of the programmers in the sample.
In a study with similar findings, Bill Curtis presented a group of 60
professional programmers with what he characterized as a "simple" debugging task
("Substantiating Programmer Variability," Proceedings of the IEEE, vol.
69, no. 7, 1981). In spite of its simplicity, 6 of the professional programmers
werent able to complete the task, and data on their performance was excluded from
the results of the study. Curtis observed order of magnitude differences among the
programmers who were able to complete the task.
What are the real-world implications of working with programmers who
cant complete their work? On a real project, "not finishing at all"
usually isnt an option, and so those programmers who didnt finish during the
Coding War games or during Curtiss debugging test would require either huge amounts
of time to complete their work or someone else would have to complete their work for them.
On real projects, these 10 to 1 differences in productivity might well translate into negative
10 to 1 differences in productivity, because eventually someone else will have to redo
the work of programmers who cant finish their assignments.
Low productivity by itself usually isnt the only problem. Strained
to the limits of their abilities by the coding activity itself, low productivity
programmers are either not able or not willing to follow project coding conventions or
design standards. They dont remove most or all of the defects from their code before
they integrate it with other peoples work, or before other people are affected by
it. They cant estimate their work reliably because they dont know for sure
whether they will even finish. Considering the absence of direct contributions to the
project and the extra work created for the rest of the team, its no exaggeration to
classify these programmers as "negative productivity programmers." The study
data suggests that about 10 percent of professional programmers might fall into this
category. A team of seven randomly selected programmers therefore has about a 50/50 chance
of including at least one negative productivity programmer.
Whose Problem Is It?
As often as managers ask what to do with problem programmers,
individual team members probably ask that question more. In a review of 32 management
teams, Larson and LaFasto found that the most consistent and intense complaint from team
members was that their team leaders were unwilling to confront and resolve problems
associated with poor performance by individual team members (Teamwork: What Must Go
Right; What Can Go Wrong. Newbury Park, CA: Sage, 1989). They reported that,
"More than any other single aspect of team leadership, members are disturbed by
leaders who are unwilling to deal directly and effectively with self-serving or
noncontributing team members." They go on to say that this is a significant
management blind spot because managers nearly always think their teams are running more
smoothly than their team members do.
On one of my projects, one programmer usually arrived at work about
10:30. He went to lunch between 12:00 and 1:30, he left the office to work out at a health
club between 3:00 and 4:30, and he left work by 6:00. The project team members were well
aware of the problem, and complained to the project manager. The project manager imposed
"core hours" that required all team members to be at the office between 9:30 and
3:30, at which point the problem programmer threw a shouting tantrum and complained about
the "abusive Draconian measures" that were being used to impose unfair
restrictions on his personal liberties.
Problem programmers are easy to identify if you know what to look for:
- They cover up their ignorance rather than trying to learn from their
teammates. They actively resist having teammates review their designs or code.
- They are territorial. "No one else can fix the bugs in my code.
Im too busy to fix them now, but Ill get to them next week." Theyll
keep files checked out of source code control exclusively for weeks at a time even when
that prevents their teammates from doing their work.
- They grumble about team decisions and continue to revisit old discussions
long after the team has moved on. "I still think we ought to go back and change the
design we were talking about two months ago. The one we picked isnt going to
Cutting Your Losses
If your organization permits it, here are three solid reasons to simply
remove the negative productivity programmer from the team:
- Its rare to see a major problem caused by lack of skill. Its
nearly always attitude, and attitudes are hard to change. If the problem is caused by lack
of ability, that is even harder to change.
- The longer you keep a disruptive person around, the more legitimacy that
person will gain in the eyes of other groups and managers, the more other peoples
work will be affected, the more code that person will be responsible foroverall, the
harder it will be to remove him from the team.
- Some managers say that they have never regretted firing anyone.
Theyve only regretted not doing it sooner.
You might worry about losing ground if you replace a team member, but on
almost any size project youll more than make up for the lost ground by eliminating a
person whos working against the rest of the team.
One of the best means of detecting problem programmers is by holding
early design and code reviews. You can identify team members who dont want to share
their work, who wont accept teammates suggestions, who wont take the
time to review other team members workin short, team members who are generally
If this early detection of problem employees fails, reviews provide a
secondary benefit of lessening the dependence on any single developer. One problem
typically associated with problem programmers is that no one else understands their
designs or code. Through design and code reviews, youll have at least two people on
the team who are familiar with every part of the program. If you find a developer on your
team who wont participate in reviews, treat that as an unacceptable risk to the
project. Insist that the developer participate in reviews, or let him go.
For the Good of the Team
Tolerating even one problem programmer hurts the morale and productivity
of the good developers. Problem programmers are often viewed as having "low
productivity," but both software research and software experience suggest that such
an assessment is too optimistic. Next time you need to improve productivity, instead of
looking for what you can add, look for who you can take away.
Editor: Steve McConnell, Construx Software, 11820 Northup
#E200, Bellevue, WA 98005.
E-mail: firstname.lastname@example.org - WWW: http://www.construx.com/stevemcc/