At 5:38am -0700 2/23/01, Chris Rasch wrote:
>Best Practices
>IEEE Software, Vol. 15, No. 2, March/April 1998
>Dealing With Problem Programmers
>Steve McConnell
>
>http://www.construx.com/stevemcc/bp14.htm
>
>"...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
This is the biggest flaw in the plug-and-play mentality of some
managers. They think that workers with similar job titles are
interchangeable. They ignore the fact that 80% of a team's work is
usually done by 20% of the team members.
>McConnell attributes most of the difference not to skill but to
>programmer attitude. He recommends early design and code reviews, and
>firing employees "....who don't want to share their work, who won't
>accept teammates' suggestions, who won't take the time to review other
>team members' work-in short, team members who are generally
>uncooperative...."
Very true, but there is a caveat. Someone has to be the best in a
group. That person should be willing to share work, but they should
not degrade their best design by taking lessor suggestions from other
team members. Sometimes this can make a brilliant employee among
idiots appear to be the problem employee. I call this the Dilbert
syndrome. Dilbert always gets in trouble when he is right and
everyone else is wrong.
>What have been you're experiences with poorly performing programmers?
>What did you find helped increase the programmer's productivity?
My experience is that managers, architects, programmers, and
debuggers are not the same people.
I believe that most of the programmers can program to some extent.
However, they may fail miserably at budgeting their resources and
time, and will never deliver on time. This is because they can't do
the project management. If a good manager would just give them
programming tasks, they would do fine.
Programmers also are not always good architects or designers. They
jump on a faulty design and fail to consider certain ramifications.
They then quickly program a project, but it has problems in testing.
Their programming was fine for the problem as they understood it.
They merely did not see some requirements or side-effects of their
task.
Debugging is the biggest skill that effects programmers. They can
slap together code that seems to work. However, when the program
fails occasionally, most programmers do not know how to debug a
problem effectively. They don't know how to isolate it to a specific
module. They don't know how to logically test all possible
circumstances to narrow down problem areas. Most programmers will
randomly read their code looking for programming errors. A good
debugger knows how to divide a problem environment into pieces, and
devise tests to determine which pieces are involved with the
problems. They then can narrow down the problem to the specific area
and can concentrate on finding the bug in a small subset of code.
I think the key to good performance is to split up these tasks to be
performed by different people, and to make sure they have those
skills Almost all companies assign a person to do a task, including
management, design, implementation, testing, delivery, etc. Even the
most brilliant people in one area are rarely good in all areas. By
forcing people to do all phases of a project,a person is guaranteed
to run into their deficiency area sometime.
-- Harvey Newstrom <http://HarveyNewstrom.com>
This archive was generated by hypermail 2b30 : Mon May 28 2001 - 09:56:47 MDT