duce an apparent increase in productivity but this was accompanied by a drop in quality. Of course, the latter did not come to light until very much later.
Towards the end of the production task, when most of the required techniques had been developed, it became very much easier to measure performance. At this stage we were better able to assess the performance of the programmers individually and the methodology had become quite standard throughout the group. The only confidence that I can gather from this experience is that of estimating the production rate for known men performing a known task that relies only on a known technology.«
Kolence: The main interest of management is in knowing what progress has been made towards reaching the final goal of the project. The difficulty is to identify observable events which mark this progress.
David: Psychology is a central point in the problem of measuring progress. Instead of looking for nice quantifiable measures, why not just ask people to give their own estimate of the amount of progress that has been made. In a controlled environment you will soon have enough evidence on which to calculate how the various individuals’ estimates should be weighted.
Fraser: (from The nature of progress in software production)
»Perhaps the most effective way of assessing the progress of a team project is to study the interface documentation. In the early stages particularly, a programming task resembles frame stressing by relaxation. The progress of the relaxation process can be assessed by studying the magnitude and pattern of successive adjustments to the structure. Similarly, the adequacy and stability of interface details provide one good measure of project status. One might even suggest, a little dangerously perhaps, that rapid change to interface descriptions is a sign of good progress and that the work content of a development project could be measured by the number of changes that must occur during the process of design development.«
Harr: (from The design and production of real-time software for Electronic Switching System)
»Each program designer’s work should be scheduled and bench marks established along the way so that the progress of both of his documentation and programs can be monitored. (Here we need a yardstick for measuring a programmer’s progress other than just program words written.) The yardstick should measure both what has been designed and how, from the standpoint of meeting the design requirements. Programmers should be required to flowchart and describe their programs as they are developed, in a standard way. The bench marks for gauging the progress of the work should be a measure of both the documents and program produced in a given amount of time.
A standard for program documentation when programs are written in symbolic machine language should be set and each program should include this standard documentation in the ‘remarks field’ of the symbolic program.
This documentation should include sufficient information and in such a way that a computer program can flow trace any program according to specified conditions.
Then a computer program can be used to assist in evaluating and checking the progress of the program design. Computer studies of the realtime used under varying conditions can be made and studies to see that memory interfaces are satisfied can be made.«
McClure: I know of one organisation that attempts to apply time and motion standards to the output of programmers. They judge a programmer by the amount of code he produces. This is guaranteed to produce insipid code — code which does the right thing but which is twice as long as necessary.
The difficulties of measuring real as opposed to apparent progress were made clear by Smith:
Smith: I’ve only been seven months with a manufacturer and I’m still bemused by the way they attempt to build software. SDS imposes rigid standards on the production of software. All documents associated with software are classified as engineering drawings. They begin with planning specification, go through functional specifications, implementation specifications, etc., etc. This activity is represented by a PERT chart with many nodes. If you look down the PERT chart you discover that all the nodes on it up until the last one produce nothing but paper. It is unfortunately true that in my organisation people confuse the menu with the meal.