Casey Reas’ talk and the story of Margaret Hamilton are related in the sense that they make think about the place of randomness and order in both art and software.
Her Code Got Humans on the Moon tells the story of how Margaret Hamilton’s work at MIT was crucial in developing the software that allowed the Apollo mission to be successful. At a glance, the most surprising thing about the story is that, in an industry dominated by men, it was a woman who spearheaded the an important part of the project. Given that unequal participation in STEM fields persists to this day, having strong female role models plays a significant role in paving the way toward more representation. For me, however, the major takeaway from the reading is the need to prototype tirelessly and build forgiving systems for users.
I extract this lesson from the fact that the NASA engineers were arrogant enough to claim that their astronauts had been “trained for perfection” and would never commit a mistake such as launching a program midflight. Hamilton had to conform herself with including a cautionary note in the documentation, instead of following her original plan of building an error-correcting mechanism into the machine. But the astronauts did make the mistake, and Hamilton and her team had to rush to save the day. From this, it becomes clear that no matter how much we’ve simulated something, our designs must incorporate error-correction, specially when we design products to be used in previously unknown situations. Being humble and forgiving in our design is not a disrespect to our users, it’s an acknowledgement that mistakes happen even when we’re most prepared. Or in other words, given the chaos that exists outside the system, software must account for as much order and structure as possible.
Casey Reas’ talk on Chance Operations relays a different message: randomness, even a little of it, can be extremely generative. Reas prefaces his examples by highlighting how, historically, the place of art has to be to incorporate order into a chaotic environment, i.e. nature, and then moves to show how with software/programmed art, that landscape or trend is changing abruptly. Through his examples, Reas demonstrates how adjusting how much we live to chance in an artwork we can embark on a journey of discovery about the behavior of form and the visual properties that emerge from it. I must emphasize, however, that this element of leaving place for randomness in code is possible only because of how rigid code can be. Code is a language of commands, it leaves no room for interpretation, and therefore we must incorporate it whenever we want it to be a part of our work.