Fun_People Archive
22 Jun
The Parable of the Two Programmers

Date: Thu, 22 Jun 95 15:47:12 PDT
From: Peter Langston <psl>
To: Fun_People
Subject: The Parable of the Two Programmers

[I know this purports to be fiction, but...  -psl]

Forwarded-by: bostic@CS.Berkeley.EDU (Keith Bostic)
Forwarded-by: cate3@netcom.com
Forwarded-by: Steve Tom <Tom>

Reprinted from ACM Software Engineering Notes, Jan 1985.

		The Parable of the Two Programmers
			Neil W. Rickert

	Once upon a time, unbeknown to each other, the "Automated
Accounting Applications Association" and the "Consolidated Computerized
Capital Corporation" decided that they needed the identical program
to perform a certain service.

	Automated hired a programmer-analyst, Alan, to solve their
problem.

	Meanwhile Consolidated decided to ask a newly hired entry-level
programmer, Charles, to tackle the job, to see if he was as good as he
pretended.

	Alan, having had experience in difficult programming projects,
decided to use the PQR structured design methodology. With this in mind
he asked his department manager to assign another three programmers as a
programming team.  Then the team went to work, churning our preliminary
reports and problem analyses.

	Back at Consolidated, Charles spent some time thinking about the
problem. His fellow employees noticed that Charles often sat with his feet
on the desk, drinking coffee. He was occasionally seen at his computer
terminal, but his office mate could tell from the rhythmic striking of
keys that he was actually playing Space Invaders.

	By now, the team at Automated was starting to write code. The
programmers were spending about half their time writing and compiling
code, and the rest of their time in conference, discussing the interfaces
between the various modules.

	His office mate noticed that Charles had finally given up on Space
Invaders. Instead he now divided his time between drinking coffee with
his feet on the table, and scribbling on little scraps of paper. His
scribbling didn't seem to be Tic Tac Toe, but it didn't exactly make much
sense, either.

	Two months have gone by. The team at Automated finally releases
an implementation timetable. In another two months they will have a test
version of the program. Then a two month period of testing and enhancing
should yield a completed version.

	The manager of Charles has by now [become] tired of seeing him
goof off. He decides to confront him. But as he walks into Charles's
office, he is surprised to see Charles busy entering code at his terminal.
He decides to postpone the confrontation, so makes some small talk then
leaves. However, he begins to keep a closer watch on Charles, so that when
the opportunity presents itself he can confront him.  Not looking forward
to an unpleasant conversation, he is pleased to notice that Charles seems
to be busy most of the time. He has even been seen to delay his lunch,
and to stay after work two or three days a week.

	At the end of three months, Charles announces he has completed
the project. He submits a 500 line program. The program appears to be
clearly written, and when tested it does everything required in the
specifications.  In fact it even has a few additional convenience features
which might significantly improve the usability of the program. The
program is put into test, and, except for one quickly corrected oversight,
performs well.

	The team at Automated has by now completed two of the four major
modules required for their program. These modules are now undergoing
testing while the other modules are completed.

	After another three weeks, Alan announces that the preliminary
version is ready one week ahead of schedule. He supplies a list of the
deficiencies that he expects to correct. The program is placed under test.
The users find a number of bugs and deficiencies, other than those listed.
As Alan explains, this is no surprise. After all this is a preliminary
version in which bugs were expected.

	After about two more months, the team has completed its production
version of the program. It consists of about 2,500 lines of code. When
tested it seems to satisfy most of the original specifications. It has
omitted on or two features, and is very fussy about the format of its
input data. However the company decides to install the program. They can
always train their data-entry staff to enter data in the strict format
required. The program is handed over to some maintenance programmers to
eventually incorporate the missing features.

	SEQUEL:

	At first Charles's supervisor was impressed. But as he read
through the source code, he realized that the project was really much
simpler than he had originally thought. It now seemed apparent that this
was not much of a challenge even for a beginning programmer.

	Charles did produce about 5 lines of code per day. This is perhaps
a little above average. However, considering the simplicity of the
program, it was nothing exceptional. Also his supervisor remembered his
two months of goofing off.

	At his next salary review Charles was given a raise which was
about half the inflation over the period. He was not given a promotion.
After about a year he became discouraged and left Consolidated.

	At Automated, Alan was complimented for completing his project on
schedule. His supervisor looked over the program. With a few minutes of
thumbing through he saw that the company standards about structured
programming were being observed. He quickly gave up attempting to read
the program however; it seemed quite incomprehensible. He realized by now
that the project was really much more complex that he had originally
assumed, and he congratulated Alan again on his achievement.

	The team had produced over 3 lines of code per programmer per day.
This was about average, but, considering the complexity of the problem,
could be considered to be exceptional. Alan was given a hefty pay raise,
and promoted to Systems Analyst as a reward for his achievement.

© 1995 Peter Langston