{"id":401,"date":"2013-06-04T10:00:51","date_gmt":"2013-06-04T15:00:51","guid":{"rendered":"http:\/\/labviewjournal.com\/?p=401"},"modified":"2019-08-14T12:06:02","modified_gmt":"2019-08-14T17:06:02","slug":"humility-3","status":"publish","type":"post","link":"https:\/\/stravaro.com\/lvjournal\/2013\/06\/humility-3\/","title":{"rendered":"Humility and Better Programming, Part 3"},"content":{"rendered":"

A programmer who truly sees his program as an extension of his own ego is not going to be trying to find all the errors in that program. On the contrary, he is going to be trying to prove that the program is correct\u2014even if this means the oversight of errors which are monstrous to another eye.<\/p>\n

\u2014 Gerald Weinberg. The Psychology of Computer Programming<\/strong><\/a><\/p><\/blockquote>\n

In this book in 1971, Dr. Weinberg described the concept of \u201cegoless programming\u201d, using a cooperative approach to programming.\u00a0 One of the main points of his book is that programming is better with teams that share their ownership of code.\u00a0 I didn\u2019t know this style of development had a name, but this is what we\u2019ve practiced on the LabVIEW R&D team since the beginning.\u00a0 The more modern \u201cagile\u201d software development methods have their roots in egoless programming.<\/p>\n

There are a bunch of great anecdotes in the book, many of which are still relevant 40 years later.\u00a0 Here\u2019s a great story that helps explain more about egoless programming\u2026<\/p>\n

<\/p>\n

A programmer (\u201cBill\u201d) was responsible for writing an important section of code at the heart of a simulation system.\u00a0 This section of code was a loop that consisted of just thirteen lines of machine code.<\/p>\n

\u2026when he finally reached the point of some confidence in it, he began looking for a critic\u2014the standard practice in this programming group.<\/p>\n

Bill found Marilyn B. 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.<\/p>\n

\u2026 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\u2014not “his” code, for that, terminology was not used here\u2014were simply facts to be exposed to investigation with an eye to future improvement, not attacks on his person.<\/p>\n

In this particular instance, Bill had been having one of his “bad programming days.” As Marilyn worked and worked over the code\u2014as she found one error after another\u2014he 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\u2026<\/p>\n

Marilyn, at the same time, did not feel any false confidence in her own work on the problem, for\u2014she reasoned correctly\u2014-where there had been seventeen errors, there were probably a few more\u2026 while Bill was giving everyone an enormous laugh at his expense, Marilyn and others managed to find three more errors before the day was over.<\/p>\n

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 that code was a wound in his pride\u2014an advertisement of his stupidity.<\/p>\n

\u2014 Gerald Weinberg. The Psychology of Computer Programming<\/strong><\/a><\/p><\/blockquote>\n

So how do you put this into everyday practice?\u00a0 I can sum it up this way\u2026 Don\u2019t work in isolation.\u00a0 Here\u2019s one major theme\u2026<\/p>\n

Review your code with others.<\/h2>\n

This is the way we do it in LabVIEW R&D.\u00a0 Approximately* all of the code that anyone submits to our source code control system is reviewed by at least one other person.\u00a0 (* There are exceptions for fixing misspellings in comments and other simple changes.)<\/p>\n

It takes courage to bare your code to others. You have to be honest and not hide anything. It seems there\u2019s always code that could have been written and documented better, designs that could have been more elegant, and error checking that could have been cleaner, weighed against getting the feature or bug fixes done in a timely manner.\u00a0 But we do it anyway.\u00a0 Remember, we\u2019re reviewing code, not reviewing the person.\u00a0 It\u2019s not about your ego; it\u2019s about creating better software. \u00a0I know that in some organizations, this will be a big culture shift.<\/p>\n

Reviewing code has multiple benefits. \u00a0It builds stronger teams, which build stronger, more maintainable applications…<\/p>\n