50 Years of Software

By Michael Martinez
Published 01/05/2019
Share this on:

Just 50 years ago, “software engineering” emerged as a field unto itself, legitimized as a branch of science and technology, joining the pantheon of professions devoted to engineering.

Today, software eats our world.

Our daily lives seem built on the languages of programmers. We furnish, clothe, and feed ourselves by going online (often with help from recommendation algorithms). Our cars run on code as much as fuel.

And chances are, you are reading this on a device whose lifeblood is software.

Now the finest minds in software — including the pioneer who invented “software engineering” — gather at this half-century milestone and look into the past and future of the revolutionary instructions that are software. Their analysis is also chronicled in the Computer Society’s IEEE Software magazine, describing the speed of software’s journey and the daunting frontiers ahead for software developers.


Software controlling the ‘social activities of the world’

Software’s evolution is nothing short of breathtaking, growing from “a small discipline in 1968, with a restricted number of experts, into a mass industry,” writes Manfred Broy, a professor at Technische Universität München and the founding president of Zentrum Digitalisierung.

“Even for a software engineer, it is amazing to see how our field has developed over the past 50 years,” Broy says in “Yesterday, Today, and Tomorrow: 50 Years of Software Engineering.”

Manfred Broy, Professor of Computer Sciences, Technische Universität München, and Founding President of the Zentrum Digitalisierung, Bayern, talks about digital transformation as a game changer for informatics at Chalmers University of Technology, Gothenburg, in March 2017.

“When dealing with the first programs, when writing the first software in the ‘50s and even in the ‘60s, no one could have expected the role software plays today. Cyber-physical systems are everywhere—and are operated by everyone.

“Software has become part of physical reality; it changes and enhances physical reality. We have to keep in mind that in 1968, most of the software was running on mainframes, not on a network and not directly connected to the processes of the real world, and was therefore quite separated from those. Nowadays, software is tightly coupled with physical processes and controls a lot of the technical and social activities of the world,” he says.

Indeed, untold fortunes are won and lost every day as Silicon Valley gambles on the next big thing in software development.

So gargantuan has been software’s growth that Broy suggests that new languages are needed.

“It is amazing that important areas of software engineering have not developed further, as is necessary considering the quick evolution of technology and applications. One example is programming languages that do not reflect the needs of today’s programming of cyberphysical systems. Our programming languages are no good for handling real-time interaction and distribution. Coding is error prone, not sufficiently abstract, and still done
too close to the machine level or at least to the OS level, mixing application logic with low-level technical systems,” he writes.

Read “Yesterday, Today, and Tomorrow: 50 Years of Software Engineering”

‘Software engineering’ inventor remembers when no schools for it even existed

The early days of software evoke a wilderness frontier, says Margaret Hamilton, the computer science pioneer who coined “software engineering while working for the Apollo spacecraft.

This robot exploration system is defined with the Function Map (FMap) RunRobot and the Type Map (TMap) Robot.
This robot exploration system is defined with the Function Map (FMap) RunRobot and the Type Map (TMap) Robot. FMaps represent the dynamic world of actions (doing) by capturing functional, temporal, and priority characteristics. TMaps represent the static world of objects (being) by capturing type, atemporal, and importance characteristics. Each map is defined in terms of the universal primitive structures: Join (J) for dependencies, Include (I) for independencies, and Or (O) for alternatives. The robot explore its environment, recording its experiences in a reactive sensorimotor memory map represented by a distributed independent set of relations, using the TMap structure dIset.

“It was not quite the ’60s,” she writes. “No school existed for learning how to build software. You were on your own. Courses, if any, were concerned only with becoming familiar with a set of available commands to tell the computer what to do (sometimes provided by a computer’s manufacturer).

“It was difficult to understand why this and only this seemed to matter. Just knowing a set of English words would not demonstrate one’s ability to write a good novel. Experience with the programming language needed on a particular project was in great demand. Little did we know that what we were doing then would become known years later as ‘software engineering,’ when we were in the trenches building flight software for the Apollo missions,” Hamilton writes in “What the Errors Tell Us.”

Hamilton details an dramatic account of the historic Apollo 11 mission when the software discovers a hardware problem and then compensates for it.

The story’s ending is magnificent.

“The Apollo 11 astronauts became the first humans to walk on the moon; our software became the first software to run on the moon. The software experience (designing it, developing it, and learning from it for future systems)
was at least as exciting as the events surrounding the mission,” Hamilton says.

Read “What the Errors Tell Us”

Agile goes mainstream

Long before there were waterfall and agile methods to developing software, there was something of a Wild West.

“Originally, computer software was written in an ad hoc manner. The programmers often had no formal training but great domain knowledge and aptitude, most commonly using large-scale nonnetworked machines and lacking a common set of principles and practices. This process was really more akin to a cottage industry than an
engineering discipline,” write Rashina Hoda of University of Auckland, Norsaremah Salleh of International Islamic University Malaysia, and John Grundy of Monash University.

The authors chronicle how agile methodologies have become “a major software engineering discipline in
both practice and research” and “the mainstream software development method of choice worldwide.”

Read “The Rise and Evolution of Agile Software Development”


The emergence of trends in agile software development.
The emergence of trends in agile software development, based on the first relevant publications in the IEEE and ACM digital libraries. SE 5 software engineering, RE 5 requirements engineering, and AR/VR 5 augmented reality or virtual reality.


Closely behind agile are DevOps and DesignOps

As software evolved the past 50 years, so did IT departments, which in the early 1960s played a supporting role in businesses to reduce costs and make operations more efficient, writes Erik Dörnenburg of ThoughtWorks in “The Path to DevOps.”

Now IT is a cross-department activity that has given rise to such terms as DevOps and DesignOps, Dornenburg writes.

Changing role of IT over the decades
The changing role of technology. For many companies, technology has become the business.

“Agile software development has led the way, and now the DevOps and DesignOps movements are hitting the mainstream. In my opinion, IT in businesses is now entirely a team activity. While there is, as ever, a need for experts with deep technical knowledge, we must focus our attention on how we get people from all disciplines working together effectively,” he says.
Read “The Path to DevOps”


What is software engineering

Professors Nancy R. Mead, David Garlan, and Mary Shaw of Carnegie Mellon University outline several challenges facing educators who teach software engineering.

The authors provided this definition of software engineering:

“Software engineering is the branch of computer science that creates practical, cost-effective solutions to computing and information-processing problems, preferentially by applying scientific knowledge, developing software systems in the service of mankind.”

Challenges facing software engineering education.
Challenges facing software engineering education.

The profession needs rigorous software engineering education based on enduring principles, and the field must reach the increasing diversity of the developer community and the diverse paths the developer takes into the profession, they write in “Half a Century of Software Engineering Education: The CMU Exemplar.”

For example, they cite how a 2016 Stack Overflow survey that found that only 19.7% of software developers had master’s degrees in computer science or related fields, and that the number of respondents who reported being self-taught was higher than the number with bachelor degrees in computer science or related fields.

Read “Half a Century of Software Engineering Education: The CMU Exemplar”


Elusive goal: Preventing security breaches

No discussion of software engineering is complete without touching upon everyone’s favorite subject, for better or for worse: hacking by bad actors.

It’s a scourge upon user and developer, alike.

What’s needed more than ever is “a more proactive approach to building secure products through continued growth in the use of the prevention and detection software security practices,” according to a new analysis of 10 years of surveys from Building Security In Maturity Model (BSIMM, pronounced “bee simm”), which has studied existing software security initiatives at 167 firms worldwide. The group informs firms on where their security in comparison to real-world practices and advises how to evolve them over time.

Three experts conducted the new analysis: Laurie Williams, the interim department head and a professor of computer science at North Carolina State University and the co-director of a U.S. National Security Agency–sponsored Science of Security lablet; Gary McGraw,the Vice President Security Technology at Synopsys and the host and producer of the Computer Society’s monthly Silver Bullet Security Podcast who’s also a principal of BSIMM; and Sammy Migues, the principal scientist at Synopsys who’s also a leader of BSIMM.

Vulnerability prevention practices

Their research found that firms could better use a software security group (SSG) for vulnerability prevention. The researchers prepared a chart, below,  that showed the percentage of 109 firms that use the 30 software security practices countering the injection of vulnerabilities. Two practices are used to prevent the injection of implementation bugs: The methodologies are used, on average, by 18 percent of the firms. Twenty-eight practices are used to prevent the injection of design flaws. These practices are used, on average, 28% of the time. Overall, the 30 practices are used 27 percent of the time, with more firms using design flaw prevention practices than implementation bug prevention practices.

Vulnerability prevention practices table

Vulnerability detection practices

Companies tend to be more reactive than proactive when dealing with vulnerabilities.

The new analysis says that 10 implementation bug practices are used, on average, by 42 percent of the firms. The 11 design flaw detection practices are used, on average, by 30 percent of the firms, indicating that more resources are focused on detecting the smaller implementation bugs. Overall, the 16 detection practices are used 36 percent of the time. For comparison purposes, the prevention practices are used 26 percent of the time. The chart below illustrates the findings:

Vulnerability detection practices table

Vulnerability response practices

Six software security practices are used to detect a breach or to respond to the detection of vulnerabilities once the product is deployed, and these six practices are used, on average, by 48 percent of the firms, as shown in the table below.

“The three practices used most often deal with emergency responses and bug fixing. The lowest-used practices are focused on proactive actions, such as fixing all occurrences of bugs. The lack of use of application behavior monitoring can be a signal for the need for research in effective behavior-monitoring tools,” the researchers say.

Vulnerability response practices table

While urging engineers to further protect society from software attacks, the experts says it’s not enough to just provide tools. Training is needed at the student and practitioner levels. And educators must help lead the way.

“Thwarting the attackers goes beyond the software engineering practices discussed in this article. Indeed, the BSIMM contains 58 other practices related to governance; organizing, managing, and measuring a software security initiative; staff development and training; and the collection of corporate knowledge used in carrying out software security activities throughout the organization. Management and product owners must evaluate and see the value in developing secure products.

“We all play a role in securing our world,” they conclude.

Read more in “Engineering Security Vulnerability Prevention, Detection, and Response”


Read other featured research from Software Engineering’s 50th Anniversary (may require a login), which won the 2019 APEX Award of Excellence in the Magazines, Journals & Tabloids–Electronic category:2019 Apex Award for IEEE Software magazine

Software Engineering Research and Industry: A Symbiotic Relationship to Foster Impact

Software Analytics: What’s Next?

Bridging the Gap: From Research to Practical Advice


Michael Martinez


About The Author

Michael Martinez, the editor of the Computer Society’s Computer.Org website and its social media, has covered technology as well as global events while on the staff at CNN, Tribune Co. (based at the Los Angeles Times), and the Washington Post. He welcomes email feedback, and you can also follow him on LinkedIn.