Vviewpoints
DOI: 10.1145/1629175.1629190
the Business of software
in praise of Bad
programmers
A tale illustrating the difference between individual and team skills.
HARoLD wAs A bad program- mer—a really bad program- mer—the kind who owed it o himself and all around him to find another profession. But Harold was a nice guy and he
was a lifer; he’d been with the company
for a long, long time. He had been a
low-level programmer forever, he never
got promoted, he received minimum
salary increases each year, and he got
moved around a lot. But nobody wanted to fire him. So every time a project
started up and needed headcount the
manager who had Harold on his team
at the time took the opportunity to unload him onto the next person unfortunate enough to have to supervise Harold. One time that person was me.
PHoto Gra PH by FlICKr user sl WorKIn G2
The scene was in the 1980s when
longevity with a company meant more
than it does today. The team I managed
was very keen. Our defining characteristic was that we wanted to become a
better team and we worked toward this
goal. We had well-defined and practiced processes, we developed and implemented requirements and design
modeling approaches, we applied and
refined a comprehensive review methodology that inspected requirements,
designs, code, test plans, test cases,
everything. We even invented an innovative new testing method. And when
we became more effective, we worked
hard at becoming even more effective.
Then Harold joined the team.
Long before Harold came on board,
the team had made a pact: we would allow no bad work, not from anyone, not
the chief designer, not the test coordinator, not the manager. Not even Harold. We would provide all the processes,
templates, support, resources, training,
reviews, feedback, and discipline necessary for every team member to be 100%
successful. We even defined the metrics
that measured this success. When Harold joined us, we laid this system out
before him and explained that following these processes was a condition of
being a member of the team. This discipline applied to everyone, even Harold.
A Program Gets Redesigned
As his first task, Harold was given one
of the easier programs to write. The
package he received prior to coding
contained good reviewed requirements,
an excellent program design complete
with graphics, a proven process for developing test conditions, and a schedule
for the ultimate inspection of his code.
While he was coding, other project issues
arose and we couldn’t keep to the review
schedule. When Harold was finally able
to bring his code for inspection he had
already unit tested it. This was in conflict
with the normal and expected process
order, but it wasn’t Harold’s fault; and
the program worked, at least according
to Harold. However, in the code review
we saw right away that the program he
wrote did not follow the reviewed and
approved design at all. Harold had not
submitted (and defended) an alternative design to the team’s systems designers; he had just written what he wanted
to write, the way he wanted to write it.
Accordingly, his code failed the inspection immediately. Harold was shocked:
“…but it passed all the tests!...” he cried.
His complaints reached all the way up to
the director of the installation, protest-
