Feeds:
RSS
Atom

The text, which I copy below, ofiginally comes from here. I am saving it in my blog because this text, though humoristic, ideally shows how programmers work and how often their work is not properly seen by superiors. I afraid that this spectacular text may disappaer in future, so I'll keep it here.

The author is Neil W. Rickert. Enjoy!

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 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 out 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  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  completed version.

The manager of Charles has by now 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  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 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  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 considered to be exceptional. Alan was given a hefty pay  raise,  and  promoted  to Systems Analyst as a reward for his achievement.

March 20, 1985

So, what programmer would you prefer? Charles or Alan?

Like it? Then bookmark it! digg.comdel.icio.usgoogle.comMyLink.deYahooMyWebTechnoratiFurllive.comnetscapeTagThatWebnews

2 Comments

  1. on Monday, 29-10-07 12:13 Michiel Roos
    Charles of course!

    ;-)
  2. on Monday, 29-10-07 21:35 Anoop
    Charles of course, then again I don't get the exact meaning of the parable? Should I think don't goof off and if you do be smarter than Charles? : )

    I actually am/have been like Charles and quite a few people at work probably think I'm useless. I've read some business papers (?) where they talk about working with techies and how it is different I'll try to look them up and post here sometime.

Leave a Reply