[SOC] The Parable of the Two Programmers
Bob N0UF
[email protected]
Tue, 28 May 2002 07:51:27 -0500
This isn't a parable, it's true.
IN 1991 I transferred to my present position in Kansas City, MO. My job
includes, UNIX and application administration and also programming in
UNIX shell script, perl and 'C' language, I also know jcl, Cobol and basic.
One of the requests my team gets all the time is to generate a report about
what happened yesterday on one or more of the systems we monitor.
My teammate had created a 5000 plus line program that he ran at the start
of each report, we average 15 to 20 reports daily, to figure out what
yesterday
was. It accounted for end of the month, end of the year and leap year. It
was
really something, large, difficult to maintain and a real system resource
hog.
The first thing I did was to run once at 0005 local time and have each
report
check it's output file to get yesterdays date. Then I rewrote it in shell
script.
My version was 154 lines and executed about 10 times faster. I then created
it using 'C' and further increased the speed and decreased the system
resources need to get yesterdays date.
I used this program for about 3 months when one day it hit me, If I execute
a simple date command at 2345 local time it's output will be yesterday
when the first report starts after midnight.
No, I didn't keep a copy of the original program. I got a headache every
time I looked at it.
73 es have fun!
Bob N0UF
PS: I've removed ALL games from my PC at work, it's just to much temptation!
----- Original Message -----
From: <[email protected]>
To: "SOC" <[email protected]>
Sent: Tuesday, May 28, 2002 6:01 AM
Subject: [SOC] The Parable of the Two Programmers
> <<<
> The Parable of the two Programmers
> Neil W. Rickert
> Dept. of Math, Stat., and Computer Science,
> University of Illinois at Chicago.
>
> Once upon a time, unbeknownst to each other, the "Automated
Accounting
> Applications Association" and the "Consolidated Computerized Capital
Corpora-
> tion" decided that they needed the identical program to perform a certain
ser-
> vice.
>
> Automated hired a programmer-analyst, Alan, to solve their problem.
>
> Meanwhile, Consolidated decided to ask a newly hired entry-level
program-
> mer, 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 out preliminary reports and
problem ana-
> lyses.
>
> 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
imple-
> mentation 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
com-
> pleted version.
>
> The manager of Charles has by now tired of seeing him goof off. He d
ecides
> 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
confron-
> tation, 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 see
> 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 one
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 though. 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
noth-
> ing 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 than 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 con-
> sidered to be exceptional. Alan was given a hefty pay raise, and
promoted to
> Systems Analyst as a reward for his achievement.
>
> >>>
>
> 73/72 !
> Claude, F5PBL
>
> http://www.qsl.net/f5pbl
> http://www.qsl.net/soc
>
> DIG #4451 - FISTS #7722 - SOC #503 - 10-X #71724
> _______________________________________________
> SOC mailing list
> [email protected]
> http://mailman.qth.net/mailman/listinfo/soc