Margaret Hamilton did not simply help put the man to the Moon. She had also invented the concept that would go along to create a major paradigm shift in ideas that people have about computers. She was the first person to make a difference between hardware and software. How do you come up with an idea of such scale and influence? - I was asking myself while watching through the video clip shared on Google’s blog a year ago. In the video, set in Mojave desert, California, we see a giant portrait of Hamilton. It is made out of mirrors that catch the moon light when darkness falls over the desert, illuminating all at once. The graphic qualities of the portrait aside, you can look at it and marvel at the tribute that earthlings pay to the legendary Apollo flight software designer, a team lead who made it possible to set human feet onto the Moon surface.
Imagine how tough it would be for Margaret and her team to write an effective piece of software, given that they’d only have it working for the first time in outer space. She’d watch its performance in the NASA mission control room with a team of four hundred thousand people who made their hard effort to make the flight to the moon possible. No pressure! The term “software engineering” itself wasn’t around back then. It was only mentioned for the first time in a 1965 letter Association for Computing Machinery (ACM), saying that Margaret H. Hamilton is the person who came up with the idea of naming the discipline, software engineering, as a way of giving it legitimacy.
So how software engineering came into existence?
Creation of a practical stored-program computer - as in the case of the 1949 demonstration of Electronic Delay Storage Automatic Calculator (EDSAC) in Cambridge, UK was doubtlessly an exciting event. Yet the realisation came quickly that instructions that we write for the machines to run need special treatment. “It was not too easy, - Maurice Wilkes from EDSAC development team recalls - to get a program right as had at one time appeared” (Campbell-Kelly, 2014:167). One wonders, what could possibly go wrong, right? This essentially meant programs now had errors. “Bugs”, as another computer scientist Grace Hopper would put it. About the same time she’d led a team creating the Mark II calculator in Harvard. With the bugs came the debugging process, which had also proven to be very, very hard. Before engineering teams involved with any kind of computer programs knew it, they ran deep into the “software crisis”, essentially a bottleneck in the advancement of the discipline. In a way, it became necessary to come up with “software engineering” as something that would address all this complexity.
How software engineering is different from software development?
No debt there is a difference between the two. One quick way of putting it is to say that software engineering encompasses everything, while development only deals with front-end work. The guide to software engineering body of knowledge (SWEBOK) puts software engineering as “the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software).” In DevSkiller’s comprehensive breakdown of the topic, picturing a software developer as a chef responsible for the food to be prepared in the best way. Continuing this metaphor engineers, who see the wider picture, supply the ingredients into the kitchen in the first place.
Back in the 1960s, the body of knowledge did not exist. Software was a mystery, a black box - as Hamilton, age 83 now, said once, the first ever software engineering team was given a lot of freedom. But they also took it seriously enough to see that they had no second chance, up there in outer space. Hamilton had to come up with an emergency protocol that would allow the software to signal to the astronauts any deviations of the program executions. She had also designed a rigorous system of debugging, a pioneering framework that would simulate any potential mission scenarios.
Summing up
The answer to how do you invent the whole new discipline, could then be answered, however preliminary, in a few ways.
1. Be a leader of a space program. The notions of “space program” and “leader” are of course scalable. The project you work on might not be such a grandiose undertaking, however something that doesn’t sound like rocket science to you, might as well be for others.
2. Have complete freedom on your hands. “It’s easier to ask for forgiveness that it is for permission” - as Grace Hopper famously said once. This means, even our day-to-day work situations often provide us with the freedom of making decisions that would allow us to peek into the new disciplines as they emerge. We just simply need to look out for them.
3. Lead a team of thousands of young rebels keen on testing the boundaries of all known.
If any of the previous requirements didn’t sound like a fairy tale, this one certainly does. However, do keep in mind that a lot has changed since the 1960s, and, crucially, online communities had emerged. This power of such communities cannot be overestimated - just look at Linux or the current state of Python - as examples of what a community can do. Besides, it is not only developers who are a part of crowds collaborations - there are, importantly, devOps and QA people too, which means that the code is not only written or dumped into forgotten repositories. It is also actively tested and deployed. Thousands of creative minds of any possible skills are not as far beyond the reach as thought before.
4. Be curious. Only curiosity will supply you with the reasons and the motivations to go forward. Reading books actually helps a lot (The pragmatic programmer anyone?) - they will help you identify new disciplines as they emerge, and tell important tectonic shifts from seasonal fashions.
Do you disagree or want to know about any of this? Have you been to Mojave and saw the monument? Leave a comment below!