I have a hard time convincing people that the study of programming is interesting. Even many of my fellow IEEE members think that the idea is strange and cannot possibly lead to any useful knowledge. “What do you expect to learn,” one of them asked me in a taunting voice, “from the conclusion that some people like to program at night and others during the day? Or if they prefer Coca-Cola while they sit at a computer, or would rather drink tea?” I usually dismiss these questions by saying that I’m just interested in how people work. However, I think the real answer is deeper. More than any other form of production, programming reflects the way we organize ourselves and the way that we think about our relations to others.

Before I go much further, I should clarify: I use the phrase “the study of programming” to refer to the human activity of producing software systems, of how teams of workers apply the ideas of computer science and software engineering to create large systems that will be used by others.

This work relates more to industrial engineering than to computer science. When my colleagues ask what I measure when I study programming, I reply that I don’t measure. The scientific method does not require quantification, even though quantification is one of the most powerful tools in science. However, quantification can lead us into studying things that are easy to measure but not particularly important. For example, it would be easy to measure how much time programmers spend typing code, erasing code, or drinking coffee. These things often don’t tell us much about the way that a programmer works.

I began observing programmers when I was an assistant dean of engineering at George Washington University. That job required me to spend a lot of time working with students. I soon found that the computer lab was the major social center for these students, even though all these individuals had computers of their own and could easily access their course materials through the campus network. I quickly saw that the students supported each other in way that they could not have done from their individual rooms. Even all the social tools, such as Facebook were no substitute for the physical presence of friends.

The students collaborated in ways that were not always obvious. They spent less time working in close teams than I had anticipated. Even when assigned group projects, they tended to work by themselves. However, the conversation was filled with words and phrases of support. They would share hints about how to handle problems. Some would identify websites that showed how to work with certain kinds of technology. The older students recounted how the course was handled with they took it the year before. Taken as a whole, these interactions tended to be disciplinary rather than informative. They helped the students keep to schedule and prevented them from avoiding tasks that were difficult or distasteful.

I have even spent a day observing programming labs at a university in Beijing. I had some time before a meeting with university administrators, so I walked the campus, found the software school, and claimed a seat in the corner. Surprisingly, no one asked who I was or why I was there. I was able to spend part of the morning simply watching the programmers work.

Now, my skill with the Chinese language is limited. Beyond a few technical computer terms, most of my vocabulary consists of words that describe food. In the US, Chinese restaurants are common in university towns and very inexpensive. Hence, many PhDs, especially those in the sciences, complete their education knowing how to use chopsticks and understanding the characters for their favorite Chinese dishes.

I saw no food in that Beijing laboratory nor heard any familiar words. However, I could understand well enough that the students were doing the same kind of things that the students in the American labs were doing. They were disciplining each other by working together, sharing ideas, and offering words of encouragement.

Commercial software development—especially the development of large complex systems—is slightly similar to academic programming. At these companies, programmers tend to work alone and offer comments that support each other rather than share technical information. However, these programmers need to spend more time coordinating their efforts; hence, they tend to have more formal meetings to discuss their work. These meetings, more than the time spent in actual coding, reveal the nature of software development.

Programming borrowed many of its ideas from the field of industrial management and planning. Indeed, many software development terms, including “to program,” came from industrial management. Hence, programmer meetings tend to be similar to planning meetings. The development team discusses plans, allocation of resources, targets, and other aspects of the plan. These ideas translate neatly into the software itself. Software projects often begin with a lengthy session in front of a whiteboard that divides the project into smaller units or modules. The programmers take turns at the board. They draw boxes to represent the different modules, and then show how the modules are interconnected by drawing lines between them.

Such diagrams represent not only the structure of the software but also represent the structure of the development team. Typically, each box corresponds to a unique group of programmers. While some groups might take responsibility for more than one box, all groups tend to have a fixed membership. Only rarely will you find a programmer who works with one team for its box and then switches to a different team for another box.

If the boxes correspond to groups of programmers, then the lines correspond to how the groups interact. We commonly assume that the lines represent technical communications protocols: data formats, processes, and calling sequences. However, they also represent the knowledge that the programming groups have of one other and how they work with each other. If no line connects two boxes, then the groups need not know anything about one another. If there is a line connecting two boxes, then the two groups need to know something about how the other works. Pioneering software engineer David Parnas argued that to think of the connections between modules as technical interfaces was a “highly dangerous oversimplification.” He claimed that the “connections between modules are the assumptions which the modules make about each other.” Because the modules cannot think, those assumptions are held by the programming teams that create the modules.

No matter how detailed a program specification is or how formally that specification is expressed, that document will always be incomplete. Ultimately, the only complete record of a system is the system itself—the code that makes it work. Even that code will not be as complete as we might like. Hidden in its files are statements that will manipulate data in a way that doesn’t properly correspond to the original design. Sometimes, these incongruous statements can lie undetected for years. They can be particularly hard to uncover when they are based on false assumptions that are shared by different programming groups.

Last spring, I attended a programming meeting to see how different groups developed and articulated their assumptions about each other. In calling the meeting, the lead developer was trying to bring some discipline to the team. He believed that they were generally working well together, but he also believed that they were starting to deviate from the original plan for the software. He wanted to make sure that all groups held common assumptions about each other and that those assumptions followed the ideas in the specification.

The meeting was long and hard. As the seats around the table were full, I had to stand against the wall but was able to get a better view of the discussions from this vantage. As in any meeting, many of the participants tried to attend to other tasks when they were not at the center of attention. Many attempted to answer email or download files. However, a senior developer kept provoking the group and asking questions that required answers of everyone. By the end of the second hour, all were aware that the lead developer’s point was that the project had expanded substantially beyond the original design.

As the meeting moved to the third and fourth hour, the group redrew the boxes, adjusted assignments, and removed feature after feature. At the end of the day, the lead developer felt that the meeting had been successful. “This is how we should be working,” he said, pointing to a new block diagram. “If you want to make any change to the plan,” he added, “you have to bring it to me and convince me that it is a good idea. If you believe the idea isn’t worth bringing to me, then it isn’t worth putting in the system.”

All technical fields have planning sessions, of course. We cannot build a road or a bridge or an airliner without assembling the technical personnel in one place to discuss the progress on the work. However, programming is a direct descendent of planning. Hence, when a group of programmers gather to discuss their work, they are actively engaged in tasks that support their effort to code the system. They are sharing technical knowledge, offering words of encouragement, and correcting false assumptions. These activities are just as important as the time that they spend sitting at their computers and staring at code.

About David Alan Grier

David Alan Grier is a writer and scholar on computing technologies and was President of the IEEE Computer Society in 2013. He writes for Computer magazine. You can find videos of his writings at video.dagrier.net. He has served as editor in chief of IEEE Annals of the History of Computing, as chair of the Magazine Operations Committee and as an editorial board member of Computer. Grier formerly wrote the monthly column “The Known World.” He is an associate professor of science and technology policy at George Washington University in Washington, DC, with a particular interest in policy regarding digital technology and professional societies. He can be reached at grier@computer.org.