The Parable of the Two Programmers · RealMensch
RealMensch
Ramblings of an old-school software developer, father, and woodworker.
Copyright © Tim Mensch, 2012-2021.<br>All rights reserved.
The Parable of the Two Programmers
Fri, Aug 25, 2017
I’m reprinting this classic here since the links I’m finding online are<br>disappearing, and I think it’s an important bit of programming<br>wisdom that I’d be sad to see disappear from the Internet.<br>– Tim Mensch
The Parable of the Two Programmers
Neil W. Rickert
Once upon a time, unbeknown to each other, the “Automated<br>Accounting Applications Association” and the “Consolidated Computerized<br>Capital Corporation” decided that they needed the identical program<br>to perform a certain service.
Automated hired a programmer-analyst, Alan, to solve their<br>problem.
Meanwhile Consolidated decided to ask a newly hired entry-level<br>programmer, Charles, to tackle the job, to see if he was as good as he<br>pretended.
Alan, having had experience in difficult programming projects,<br>decided to use the PQR structured design methodology. With this in mind<br>he asked his department manager to assign another three programmers as a<br>programming team. Then the team went to work, churning our preliminary<br>reports and problem analyses.
Back at Consolidated, Charles spent some time thinking about the<br>problem. His fellow employees noticed that Charles often sat with his feet<br>on the desk, drinking coffee. He was occasionally seen at his computer<br>terminal, but his office mate could tell from the rhythmic striking of<br>keys that he was actually playing Space Invaders.
By now, the team at Automated was starting to write code. The<br>programmers were spending about half their time writing and compiling<br>code, and the rest of their time in conference, discussing the interfaces<br>between the various modules.
His office mate noticed that Charles had finally given up on Space<br>Invaders. Instead he now divided his time between drinking coffee with<br>his feet on the table, and scribbling on little scraps of paper. His<br>scribbling didn’t seem to be Tic Tac Toe, but it didn’t exactly make much<br>sense, either.
Two months have gone by. The team at Automated finally releases<br>an implementation timetable. In another two months they will have a test<br>version of the program. Then a two month period of testing and enhancing<br>should yield a completed version.
The manager of Charles has by now [become] tired of seeing him<br>goof off. He decides to confront him. But as he walks into Charles’s<br>office, he is surprised to see Charles busy entering code at his terminal.<br>He decides to postpone the confrontation, so makes some small talk then<br>leaves. However, he begins to keep a closer watch on Charles, so that when<br>the opportunity presents itself he can confront him. Not looking forward<br>to an unpleasant conversation, he is pleased to notice that Charles seems<br>to be busy most of the time. He has even been seen to delay his lunch,<br>and to stay after work two or three days a week.
At the end of three months, Charles announces he has completed<br>the project. He submits a 500 line program. The program appears to be<br>clearly written, and when tested it does everything required in the<br>specifications. In fact it even has a few additional convenience features<br>which might significantly improve the usability of the program. The<br>program is put into test, and, except for one quickly corrected oversight,<br>performs well.
The team at Automated has by now completed two of the four major<br>modules required for their program. These modules are now undergoing<br>testing while the other modules are completed.
After another three weeks, Alan announces that the preliminary<br>version is ready one week ahead of schedule. He supplies a list of the<br>deficiencies that he expects to correct. The program is placed under test.<br>The users find a number of bugs and deficiencies, other than those listed.<br>As Alan explains, this is no surprise. After all this is a preliminary<br>version in which bugs were expected.
After about two more months, the team has completed its production<br>version of the program. It consists of about 2,500 lines of code. When<br>tested it seems to satisfy most of the original specifications. It has<br>omitted on or two features, and is very fussy about the format of its<br>input data. However the company decides to install the program. They can<br>always train their data-entry staff to enter data in the strict format<br>required. The program is handed over to some maintenance programmers to<br>eventually incorporate the missing features.
SEQUEL:
At first Charles’s supervisor was impressed. But as he read<br>through the source code, he realized that the project was really much<br>simpler than he had originally thought. It now seemed apparent that this<br>was not much of a challenge even for a beginning programmer.
Charles did produce about 5 lines of code per day. This is perhaps<br>a little above average....