Sharing is no panacea

From Chapter 3: The Surgical Team

Excerpt
Absolutely vital to Mills's concept is the transformation of programming "from private art to public practice" by making all the computer runs visible to all team members and identifying all programs and data as team property, not private property. (p. 32)

From You and Your Research¹

[Newton] said, "If I have seen further than others, it is because I've stood on the shoulders of giants." These days we stand on each other's feet!²— Richard Hamming

Brooks demands "public practice" because hiding code impedes communication. There is great merit in the suggestion because many development problems stem from the lack of information about the evolving design. In fact, Brooks suggests that the team include a full-time, "Program Clerk" whose primary task is to keep the code in an open library where it can be seen by all team members.

That was then before Source Control Systems made sharing code routine. But code sharing is not the paradise Brooks envisioned. Like an ice cream-based weight-loss cure, the arrival of effortless sharing is wonderful in theory, but too good to be true.

Why? First of all sharing qua sharing is no panacea. What good is there in sharing artifacts that are unintelligible?

The current generation of programming technologies can make code very hard to understand—much harder than 40 years ago. If a programmer uses object-oriented inheritance, generic programing, aspect-oriented programming or dynamic binding, the actual behavior of the program may not be apparent by just looking at a few source code files. If you find yourself trying to grok a non-trivial program, chances are good that you'll be studying the interaction of code in a few dozens of source files, pondering hundreds of pages of cryptic web docs, and spending a few weeks of runtime debugging in order to really understand what that the code is doing.

Brooks recognized most code is not built to be used or understood by other programmers. He explained that if code is intended to be used by others, the development costs may jump by an order of magnitude. The multiplier depends on the type of system product being built. Here's how he classifies those different product types:

Brooks'software product classification

Brooks' breakdown of of software  product types
(from page 5, Mythical Man-Month )

1. A Program
   • The simplest of the product types.
   • Built to be run by the programmer who wrote the program—typically a domain expert.
   • "Commonly produced in a garage."
   • Vast majority of products developed to support NASA missions.
2. A Programming System
   • Collection of interacting programs that work together.
   • Assemblage consists of an entire facility.
   • Requires careful control of interfaces.
   • So long as the interfaces are controlled, the system will work without code sharing.
   • Brooks estimates the cost of a 'Programming System' is 3 times as much as just 'A Program.' However, the cost grows geometrically with the number of interacting programs.
   • Grows brittle with age. The system gets brittle as it ages; changes to one program may break many others.(see Maintenance Mindset)
   • NASA ground systems are 'Programming Systems.' Most are several decades old, brittle, antiquated and very expensive to maintain.
3. A Programming Product
   • Intended to be fixed and used by anyone.
   • Written in a generalizable fashion.
   • Well documented.
   • Includes effective set of test programs.
   • Works on many different operating environments and with different data sets.
   • Costs 3 times as much as just 'A Program.'
   • Typical of a commercial product. For financial and cultural reasons, NASA does not produce programming products.
4. A Programming Systems Product
   • Combined capabilities of the 'programming system and the 'Programming Product.'
   • Today a 'Programming Systems Product' is called a framework.
   • A 'Programming Systems Product' is cost 9 times as much as a 'Program.' (Ouch!)

Aside from the significant increase in the cost of building a product that's intended to be shared, there are other reasons why sharing is no cure all. Consider the plight of the poor programmer:

• Programmers work in an engineering culture which is intolerant of errors.
• Any non-trivial program will have bugs.
• A programmer's code can be broken by the work of another programmer. That 'other' programmer could work on the same team or another team.
• Broken code has consequences. It often creates a lot of extra work that may threaten the schedule.
• Programmers tend to delay exposing a flaw in their own code as long as possible because in most cases it will be fixed in time. The interim can be nerve wracking.
• Programmers are quick to expose a flaw in someone else's code because a quick fix may help with the assignment at hand or because it helps buy more coding time.
• It is often difficult to identify who was responsible for a specific break.
• The specific cause of a breakage is seldom black and white. In a large bureaucracy, like NASA, there can be political consequences for the programmer or programming team considered the offender.

By and large, programmers are a very bright bunch who quickly learn how to protect themselves. One of the best methods of self defense is a good offense. This especially true when an harried manager must rely on his 'go-to' programmer for an appraisal of coding progress and any potential threat to his primary concerns: cost and schedule.

Cultivating a manager's trust is an art; but not necessarily a Machiavellian one. Top-notch programmers are a highly-competitive, self-confident lot.³ They know how to inspire confidence.

During the years I worked on development projects I came to recognized a few traits common to the most talented coders:

• They have a better command of programming languages and thoroughly understand the operation of the compiler and/or the interpreter.
• They are great debuggers. Parsing a 50-line output from stderr is a piece of cake.
• They have an uncanny mastery of multi-threaded programming which by any account is an arcane art.
• The have the ability to grasp the long-term consequences of code organization and data structure.
• They are often highly critical of other programmers and are adept at finding fault.
• They believe they can do most any job and do it better than it was done by the last guy.

Would you want to share your code with someone like that?! Isn't it reasonable ask why anyone would want to make it easy for an outsider to erode the confidence of upper management. Is it any wonder that teams are reluctant to share?⁴

This reluctance to share is standard practice among flight software teams. It doesn't matter if you have every imagined credential, you will not get access to the code unless you are on that flight software team.

So happens that government-funded projects are required by law to share the code with others doing government work.⁵ It is illegal to withhold the code. Yet, in common practice, it is common for the project to withhold code. No one in the project complains. It's a very effective way to keep the flight software from the prying eyes of engineers who might expose fundamental design flaws.

Don't get me wrong. Code sharing is good and much better than keeping it private. However, it's not enough to simply make it available. It must be made available in a form that can be readily understood. But, intelligibility costs and THAT is the real challenge. How do we affordably create programs for a complex system with code that can be readily understood? This is, and has been, an area of active research. Progress has been very slow. We have a long way to go.

On the other hand, competition among top-notch programmers and programming teams will always be intense. Especially in the space business where government funding is a zero-sum game. So, if you share code, stay alert. Someone might be looking for a good pair of feet to stand on.

---

^1. Hamming. R. "You and Your Research." Transcription of the Bell Communications Research Colloquium Seminar 7 March 1986. J. F. Kaiser, Bell Communications Research.
^2. A another version of this quote, "Physicist make progress by standing on one another's shoulders, Programmers make progress by standing on one another's feet." is often attributed to Watts Humphrey.
^3. I never considered myself to better than a middling programmer.
^4. There's an interestingly sharp contrast with unfunded open-source development where programmers are eager to share. The competition for funding makes all the difference because funds can't be shared without a cost.
^5. The code can be shared with any business or institution doing government work under a government-use license (Title 37: Patents, Trademarks, and Copyrights PART 404—LICENSING OF GOVERNMENT-OWNED INVENTIONS §404.4 Authority to grant licenses.). No license is required when sharing occurs for work that being done under the same task order.