A Brief History of Software Engineering — Part 1
A collection of stories and events behind the emergence of one of the most unique branches of engineering.
As per Wikipedia,
Software engineering is a systematic engineering approach to software development.
Now as simple as that definition is and as self-explanatory of a term Software Engineering is, its history is anything but.
From the humble beginnings where one half of the term, Software, had to earn the other, to growing into a giant market with a projected revenue of over 600 billion dollars (as of 2022), I’d say it has come a long way.
But how did we get here? To answer that, we will have to go all the way back to when it all started. See, it all started… some time back in the 60s?
See, that’s the thing, it’s a little complicated.
The Origins
If you look it up, you’ll find many origin stories for the term Software Engineering. You have a letter written to ACM membership by Anthony Oettinger, then ACM president at Harvard University.
In which he emphasizes on focusing more on the practical side of engineering, which includes software engineering as well.
You got conferences held by NATO Science Committee in 1968 and 1969, specifically to lay some sort of groundwork on how to go ahead with this emerging field. From the 1968 conference report,
The discussions cover all aspects of software including
• relation of software to the hardware of computers
• design of software
• production, or implementation of software
• distribution of software
• service on software.
These conferences were also meant to find a solution to the challenges that were identified as softwares began to make their way into the commercial market.
• the problems of achieving sufficient reliability in the data systems which are becoming increasingly integrated into the central activities of modern society
• the difficulties of meeting schedules and specifications on large software projects
• the education of software (or data systems) engineers
• the highly controversial question of whether software should be priced separately from hardware.
(Full disclosure, I did not know NATO had its own Science Committee, I mean Engineering isn’t exactly the first thing that comes to mind when you think of NATO, is it)
And I find it amazing that even back then these people could sense how big of a thing softwares were going to be. I mean, think about it for a minute, at that time you did not have cloud providers, you did not have social media, you did not have smartphones. For most of the people, softwares were just a piece of program that came pre-packaged with the hardware that they actually wanted. Something intangible, a small cog in a way bigger machine.
And even during those times, this committee probably knew that this “intangible something” is going to be the soul of all the advanced, powerful hardware to come. And that without it, they will all be nothing more than a pile of very sophisticated materials. So much so that they wanted to make sure to establish all the best practices beforehand. Best practices that impact us to this day, maybe more so than ever.
Alright, corny tangent aside. These conferences played a major role in boosting the software industry and giving it a more firm foundation. But as crucial as it may sound, my personal favorite is a different story.
A story about the Goddess of Software. Margaret Hamilton.
The Goddess of Software
To give you an idea of who we are dealing with here, during her time working on the SAGE project at MIT Lincoln Lab, she was assigned a program that nobody could ever get to run. This was sort of a standard practice there to assign this program to new members who were beginners. And guess what, she freaking solved it. Until that point, no one had ever been able to do what she did. She got it to work and even got the expected results printed in Greek and Latin. I’m sure people at SAGE knew right then this was someone special. But for her that was just the beginning, because she was about to be a part of, no, be a critical factor in ensuring the success of one of our race’s greatest achievements. Enter, NASA.
Margaret’s role in the Apollo project
As part of the Apollo project, NASA got in a contract with MIT Instrumentation Laboratory to develop system softwares for navigation and lunar landing guidance. Since software engineers weren’t as common back then as they are today, MIT posted a newspaper ad, that they were looking for people to develop software to “send man to the moon”. Love the lack of subtlety here. I mean, who can resist that.
Co-incidentally, Margaret’s husband saw this ad and like I said, who can resist this offer. Margaret was the first programmer and the first woman they hired for this program. She just can’t stop achieving milestones, can she?
Margaret was initially hired as a programmer, but eventually she became the leader of the team that was credited with developing all the softwares for Apollo. To be precise, Apollo 11 had two onboard computers: one on the command module Columbia and the other on the Lunar module, Eagle. Margaret’s team was tasked with developing the common system software (which you can think of as a rudimentary OS) and the softwares that were supposed to run on top of that. NASA and MIT initially underestimated how big and critical this task was, but over time they realized how much they were relying on the softwares to perform some major operations. As a result, this team grew to have almost 100 software engineers, that too, in a time when Software Engineering wasn’t exactly a thing, at least not the way it is today.
Her team was also responsible for developing error detection and recovery softwares as part of the system software developed for Apollo. These included Display Interface Routines, or Priority Displays that pop up on your screen as a warning that something isn’t quite right. Yes, this was when they came into existence, the Priority Display Prompts we are so used to today were also developed by Margaret. Add that to the list.
During its early days, the whole software side of the Apollo project wasn’t given as much respect as the other engineering disciplines. It wasn’t considered as crucial or as big of a contributor as, let’s say, hardware. The prevalent idea was that the hardware itself along with the training given to the astronauts would be enough to handle any issues they might run into. Any effort put into perfecting the software was considered just an additional safety net, a redundancy.
Margaret however knew very well what a failure in one of her software programs could lead to. She understood that these programs had to generate accurate results, that even the smallest error could lead to anything from the spaceship going off course to a crash landing. Understanding the importance of her and her team’s work in the bigger picture, she wanted this job to be paid the same respect as any other engineering field. In her own words,
I fought to bring the software legitimacy so that it — and those building it — would be given its due respect, and thus I began to use the term ‘software engineering’ to distinguish it from hardware and other kinds of engineering, yet treat each type of engineering as part of the overall systems engineering process. When I first started using this phrase, it was considered to be quite amusing. It was an ongoing joke for a long time. They liked to kid me about my radical ideas. Software eventually and necessarily gained the same respect as any other discipline
Not meaning to disagree with a goddess, I’d like to rephrase her last sentence. Software eventually earned the respect it was due. And she played a huge role in making that happen.
When the giant leap could have gone wrong
Three minutes before Apollo 11 was about to land on the moon, computers aboard Eagle and the Lunar lander interrupted the astronauts with alarms to warn that there was an emergency, and that the computer was overloaded. There were multiple underlying reasons for these warnings. Aldrin leaving the radar switch open, discrepancy between altitude measurements by Eagle’s landing radar and its internal guidance system, and a breath of oxygen left in the airlock increasing the descent speed.
These computers were running on memory less than what a Fitbit comes with today. This overloading could very well have crashed the system, potentially aborting the mission and putting the astronauts in danger, as they were relying on the software to help them with navigation and landing. But right then, something amazing happened. The software started compensating for all the extra computation requests it was receiving. The error detection and recovery mechanism I talked about earlier kicked in, and the system started rebooting and executing the tasks according to their priority.
All of this was foreseen by Margaret. The astronauts landed successfully because Margaret made sure that even if things go south, her software will take care of it all.
I swear this must have been like her anime moment with her safety net coming to the rescue right when things were at their worst to save the day.
The power and importance of Software Engineering was proven that day. And of course, this is not the only story where it wins the day, but this one is my favorite.
Oh, and now that we can move past the origins, let’s move on to the next phase. Software Engineering has earned its place, but that also came with big expectations. And considering the way software programs and the developers of that time worked, given the requirements they were accustomed to. They were not ready.
A crisis lay ahead, and I mean it quite literally. It was a time when Software Engineering had to grow beyond its existing limitations and take that first step towards becoming the giant it is today. A phase also known as, The Software Crisis.
But, that’s a story for another time. And from what I’ve researched so far, we’re in for a ride.
Hope you enjoyed this read, maybe you learned a thing or two as well, or maybe you were here just for the story. Either way, I hope you have a great day ahead, and maybe I’ll see you next time.
Thanks for tagging along. Feel free to share any thoughts, suggestions, or corrections down in the comments.
See you on another story.
