As president of the IEEE Computer Society, I have had to talk to a lot of reporters about the state of technology. Over the past year, I have had to discuss 3D printing, the recent Chinese supercomputer, and the Internet of Things. In early November, shortly after I returned from the Chinese National Computing Congress, I had to talk about the nature of the society itself.

Earlier in the fall, a business organization had called the Computer Society “the union of software engineers.” The claim that the Computer Society was a trade union for software engineers came in the midst of a political discussion. The business group was trying to get the American government to spend more money educating software engineers. They believed that they could get more sympathy for their position if they characterized us as a union.

In the United States, unions represent workers in specific industries, such as the auto industry, or the transportation industry, or even the service industry. They are often accused of supporting workers at the expense of business. Specifically, they are accused of trying to limit the number of workers in order to drive up wages.

In fact, the Computer Society is not a union or anything close to a union. It does not represent software engineers nor does it try to limit the number of engineers. However, it does try to define the skills that are needed by engineers and it does this through standards and through a product called the Guide to the Software Engineering Body of Knowledge (SWEBOK).

Software engineering is a very new engineering discipline. It can trace its origins only to the 1960s. By contrast, electrical engineering has a history that goes back to the 1880s, mechanical engineering has one that stretches back to the 18th century, and civil engineering has a history that can be dated to the third century BC in the Mediterranean or the Song Dynasty in China.

We generally identify 1968 as starting date for software engineering. That year marks a period in the computing industry that was known as the “Programmer Crisis.” Prior to 1968, any organization that used a computer also had to create its own software. There was no software industry, no common systems, no open source. Throughout the 1960s, the number of computers had been growing rapidly. By 1968, there were roughly 50,000 operating machines in the world.

Well before 1968, computing centers were finding it difficult to hire all the programmers that they needed at the price that they wanted to pay. Businesses talked about how they needed to train new programmers and how the world would need a million new programmers by 1970 just to keep up with demand. However, by 1968, people were beginning to realize that they might be able to address the programmer crisis in ways that used far fewer programmers. Instead of encouraging businesses to write their own software, a single team of programmers could create software that would be used by many different computers at many different sites.

If a single program was going to work on different sites, it would have to be well written, simply organized, and free of errors. In short, it would have to be carefully engineered. However, prior to 1968, no one had given much thought to how one might actually engineer software. Yet, in that year, a group of programmers met at a conference in Garmisch Germany to talk about how software might be engineered and what techniques might be used in software engineering.

A number of speakers talked about engineering software by organizing the code in a structured and systematic manner. Others suggested that software engineering might be similar to mechanical engineering. In such a scenario, software would have standard parts, standard ways of assembling objects, and standard ways of describing the final system. Programmers need a “software components industry,” argued one engineer. “The most important characteristic of a software components industry is that it will offer families of routines for any given job.”

Ultimately, neither the idea that code should be carefully structured nor the plan that software production was something like mechanical engineering formed the basis for software engineering. Ultimately, software engineers borrowed many of their ideas from the practice of quality control and developed their field at IEEE Computer Society

The Computer Society was formed in 1970, though IEEE members had been developing the ideas of computation and programming for over 25 years. The new organization quickly assembled committees to consider software engineering and how to create high quality software. The first of these standards, IEEE 829, was released in 1983. It described how to document the tests that a programming team would use to validate a new software system.

The standard IEEE 829 was quickly followed by others, including IEEE 730, which described how to make plans for assuring the quality of software and IEEE 1074, which described the software lifecycle. The IEEE 1074 standard argued that software needed to be constantly updated. It suggested that engineers needed to plan their work in a cycle that had 6-8 steps. An example of the software lifecycle is given below.

In creating a new software system, engineers would first determine what the software had to do. This is the requirements step. In the next three steps, they would design the software, code the system and debug it.

Next, they would configure the system and install it. Once they had installed the system, they could operate it and gather data about how well the new software worked. Inevitably, they would find errors, mistakes, and even bad specifications. In the last step of the cycle, they would determine which issues needed to be addressed and then they would return to the start of the software lifecycle. They would create the requirements for the additions to the package, design the changes, and continue around the circle.

The software lifecycle was officially codified in 1995 as International Standard Organization (ISO) Standard 12207. This standard defines what it means to be a software engineer. While the IEEE still had other standards to write, it also began to consider how you educated software engineers. As part of this educational effort, they began work on SWEBOK.

SWEBOK not only described the software lifecycle, it also pointed to articles and documents that supported each state of that lifecycle. Originally adopted in 2004, it is also an ISO standard, with the number ISO-IEC TR 19759-2005. After nine years, it has been updated. In the final weeks of 2013, the Computer Society Board of Governors approved SWEBOK Version 3. The society anticipates that the basic topics of this version will not change much in the coming year, though it plans to update SWEBOK more regularly.

Ultimately, SWEBOK is one of our more important products. It may not be as exciting as 3D printing nor as engaging as the Web of Things but it establishes the field of software engineering. Such a task is not the work of a trade union. Trade unions organize workers and represent their interests to businesses. The Computer Society defines an important class of professional workers and helps those workers create the intellectual tools to do their work. It is a task that has engaged us for nearly 45 years.

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.