Conclusiones finales y recomendaciones

One of the big problems of controlling the production of a large system is obtaining information which will reveal how much progress has been made.

Fraser: (from The nature of progress in software production)

»One of the problems that is central to the software production process is to identify the nature of progress and to find some way of measuring it. Only one thing seems to be clear just now. It is that program construction is not always a simple progression in which each act of assembly represents a distinct forward step and that the final product can be described simply as the sum of many sub-assemblies.

…

Various attempts were made at measuring progress without much success. As the work advanced we evolved a simple method of accounting for the components that went to form or support the final product. But this approach was no better than the various ‘seat of the pants’ methods which 87 are still much in evidence. We experienced one of the classic problems of metering: that of interference between the measuring device and the process that is being measured. At one time we kept totals of the number of subroutines that were classed as ‘tested’ and compared this number with the total number of subroutines in the final product. But, once a programmer’s performance is formalised in this way it changes his attitude to his work. The effect was to pro-

52

5. Production

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 con- fidence 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 documenta- tion. 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.«

88

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 measur- ing 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 soft- ware. 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, 89 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.

53

5. Production

The analogy with engineering drawings, however, raised the question of measuring the quality of work produced, as well as progress towards the project goal.

McIlroy: I think we should consider patterning our management methods after those used in the preparation of engi- neering drawings. A drawing in a large organisation is usually signed by the draughtsman, and then after that by a draughting supervisor when he agrees that it looks nice. In programming efforts you generally do not see that second signature — nor even the first, for that matter. Clarity and style seem to count for nothing — the only thing that counts is whether the program works when put in place. It seems to me that it is important that we should impose these types of aesthetic standards.

McClure: I know of very few programming establishments where supervisors actually bother to read the code pro- duced by their staff and make some effort to understand it. I believe that this is absolutely essential.

Buxton: I know of very few programming establishments in which the supervisor is capable of reading code — some present company excepted!