Egoless Programming

March 11, 2018

Egoless Programming

Egoless programming is a concept introduced by Gerald Weinberg in The Psychology Of Computer Programming. The idea is that programmers must fight the natural tendency to treat their programs as part of themselves, and therefore to reject all criticism. Rather, they should do their best to treat their designs & implementations as objects independent of themselves, and to view criticism dispassionately on its merits. What is to be done about the ego problem in programming? A typical text on management would say that the manager should urge all his programmers to reinforce their efforts to find their errors. Perhaps he would go around asking them to show him their errors each day. This method, however, would fail by going precisely in the opposite direction to what our knowledge of psychology would dictate, for the average person is going to view such an investigation as a personal trial. Besides, not all programmers have managers – or managers who would know an error even if they saw one outlined in red.

No, the solution to this problem lies not in a direct attack – for attack can only lead to defense, and defense is what we are trying to eliminate. Instead, the problem of ego must be overcome by a restructuring of the social environment and, through this means, a restructuring of the value system of the programmers in that environment. Before we discuss how this might be done, let us look at some examples of what has happened when it has been done – how it affects the programmers and their programs.

The problem of ego must be overcome by a restructuring of the social environment. – Gerald M Weinberg

What is a value system?

A person’s standards and self-discipline set, based on the common sense and wisdom of knowing what the proper moral rules and discipline are, and the amount of willingness to see themselves and others abide by them.

First of all, let no one imagine that such restructuring is the ivory tower dream of social theorists. Programming groups who have conquered the ego problem do exist and have existed from the earliest days of computing. John von Neumann himself was perhaps the first programmer to recognise his inadequacies with respect to examination of his own work. Those who knew him have said that he was constantly asserting what a lousy programmer he was, and that he incessantly pushed his programs on other people to read for errors and clumsiness.

Yet the common image today of von Neumann is of the unparalleled computing genius – flawless in his every action. And indeed, there can be no doubt of von Neumann’s genius. His very ability to realise his human limitations put him head and shoulders above the average programmer today.

Your ability to realise your human limitations will put you head and shoulders above the average programmer today. – John von Neumann

Average people can be trained to accept their humanity – their inability to function like a machine – and to value it and work with others so as to keep it under the kind of control needed if programming is to be successful.

Begin looking for a critic

Who can be a critic?

Someone willing to look through your code in exchange for returning the favour. Whenever possible an exchange should be made, so nobody would feel in the position of being criticised by someone else.

A Story?

illustration-of-a-flat-style-rocket-on-an-unknown-planet_1441-202.jpg

Consider the case of Bill who was working in one of the early space tracking systems. His job was to write a simulator which would simulate the entire network of tracking stations and other real-time inputs. His system had to check out the rest of the system in real-time without having to have the worldwide network on-line. The heart of the simulator was to be a very small and very tight loop, consisting, in fact, of just thirteen machine instructions. Bill had worked for some time on this loop and when he finally reached the point of some confidence in it, he began looking for a critic – the standard practice in this programming group.

Looking for a critic

Bill found Marilyn willing to peruse his code in exchange for his returning the favor. This was nothing unusual in this group; indeed, nobody would have thought of going on the machine without such scrutiny by a second party. Whenever possible an exchange was made, so nobody would feel in that position of being criticized by someone else. But for Bill, who was well schooled in this method, the protection of an exchange was not necessary. His value system, when it came to programming, dictated that secretive possessive programming was bad and that open, shared programming was good.

Errors that might be found in code he had written – not “his” code, for that terminology was not used here – were simply facts to be exposed to investigation with an eye to future improvement, not attacks on his person.

Bad programming days

In this particular instance, Bill had been having one his “bad programming days”. As Marilyn worked and worked over the code – as she found one error after another – he became more and more amused, rather than more and more defensive as he might have done had he been trained as so many of our programmers are. Finally, he emerged from their conference announcing to the world the startling fact that Marilyn had been able to find seventeen bugs in only thirteen statements. He insisted on showing everyone who would listen how this had been possible. In fact, since the very exercise had proved to him that this was not his day for coding, he simply spent the rest of the day telling and retelling the episode in all its hilarious details.

False Confidence

Marilyn, at the same time, did not feel any false confidence in her own work on the problem, for – she reasoned correctly – where there had been 17 errors, there were probably a few more. In particular, she knew that after a certain amount of time working on the code, she had internalized it as much as had Bill, even though she had not written it originally. So she in turn went looking for a critic; and while Bill was giving everyone an enormous laugh at his expense, Marilyn and others managed to find 3 more errors before the day was over.

As an epilogue to this incident, it should be noted that when this code was finally put on the computer, no further errors were found, in spite of the most diabolical testing possible. In fact, this simulator was put into use in more than a dozen installations for real-time operations, and over a period of at least nine years no other errors were ever found. How different might have been the story had Bill felt that each error found in the code was a wound in his pride – an advertisement of his stupidity.

Strengths & Weaknesses:

Why not so popular?

This incident is not an isolated case, and this group is not unique. Why, then, are such groups not more apparent? Why is the practice of “egoless programming” not more widespread? A number of factors might be invoked to account for the impression that such groups are rare.

Proprietary Information

First of all, many of the successful software firms are based on this type of interaction and though they will admit to it under direct questioning, they often regard this knowledge as valuable proprietary information.

Hard to find

Secondly, groups working on this way tend to be remarkably satisfied and stable, so that the programmers we find wandering from company to company are not likely to have come from such a group.

The Myth of Genius

More, these gypsy programmers – to achieve a constantly escalating salary range – must encourage the myth that the best programming is the product of genius, and nothing else.

Difference in quality of work

Another reason these methods are not better known is that nobody has ever experimented on the difference in quality of work produced by this method and the method of isolated individual programmers. Some experiments have been performed on factors affecting programmer productivity, but these have suffered first of all from emphasis on the mechanical aspects of programming, not the social. For example, a study will be made comparing time sharing with batch processing or language A with language B, because someone is trying to prove that he should be allowed to develop a time-sharing system or a compiler for language B. The people who run these experiments seem to take for granted the individual nature of programming effort – for that is probably the way they have always operated. Besides, things are complicated enough working with individuals. When you compare system X and system Y and find out that 90 percent of the variance in your experiment comes from individual programmer differences, who wants to add the complication and expense of studying group performance?

Efficient Coding vs Quick Completion

An interesting anecdote – can be told about one of the studies that tried to assess the difference in programming results obtained when different programmers were given slightly different impressions of what they were to achieve – efficient coding or quick completion. As usual, individual subjects were employed, but one of these subjects – they were all students on a special three-month course – happened to come from a group that practiced egoless programming. At a certain point, he came to me and said that he had reached the point in his work where he needed someone to look over what he had done. As the object of the experiments was not to study differences between group work and individual work, to request that the subject try to proceed without outside assistance, which would only add to the variance of the experiment. As a sidelight to this incident, it should be noted that this programmer’s work seemed to the evaluators to be better organized and better executed than the other four programmers working on the same problem. In discussing this question with him, he raised the point that he had worked throughout as he always did in his own group – always with an eye to making the program clear and understandable to the person or people who would ultimately have to read it.

Always work with an eye to making the program clear & understandable to others.

This insight indicates that all the advantages of egoless programming are not confined to the detection of errors, though that was perhaps the earliest and strongest motivation for adopting the technique. In fact, it might be useful to examine our four factors in good programming in the light of what effect this method would have on them.

All the advantages of egoless programming are not confined to the detection of errors.

Meeting specifications and schedule

For meeting specifications, the value is quite clear. On the matter of scheduling, the effect on the mean time to complete programs is not immediately evident, but the effect on the variation should be clear from our example of the bugged simulator. If it is true that programmers have bad coding days – and this seems supported from a number of sources – then a piece of code written on one of these days is going to have an extra long debugging cycle. In the case of Bill’s program, the twenty bugs might have taken several weeks to root out. Moreover it seems likely that at least one of them might have survived in the system past the time when this piece was integrated with other pieces – in which case the schedule of other parts would have been adversely, or at least unpredictably, affected. Not only is the variation in debugging time reduced, but since there is more than one person familiar with the program, it is easier to get realistic estimates on the amount of real progress that has been made.

It is not necessary to rely on a single judgment – and of the person least likely to be unbiased, at that.

Adaptability

The adaptability of programs is also improved, for we are assured that at least two people are capable of understanding the program. Under certain programming circumstances, this represents an infinite improvement. Also, the entire work is less susceptible to being disturbed if one of the involved programmers happens to be sick, or pregnant, or otherwise missing, as programmers are wont to be. This not only reduces variations in schedule, but also makes it more likely that at some time in the future, when the code must be modified, someone will be around who knows something about it. On the question of efficiency, we can make no hard and fast statements. There certainly seems to be no reason why programs are developed in this way should be less efficient than other programs.

Scrutiny by a second party

By having a second party look at the program, it would seem that we increase the possibility of eliminating at least the most obviously inefficient areas, although overall efficiency is usually going to be primarily influenced by the original structure chosen.

Become a better programmer

One final advantage of this method lies in the effect it has on the person reading the program of someone else, for, if we are correct in assessing the value of reading programs, he cannot help but become a better programmer for the exercise. It does seem that the general level of competence of such a group is likely to raise itself even in the absence of specific measures for education.

Egoless Programming