In the last post I mentioned Stuart Brand’s idea that architecture is dynamic and how software application is similar in this regard. In both cases, the designer needs to design for change, creating a flexible yet reliable structure that accommodates future extension and modification.
What’s different, however, is how designer participates in these changes. After the building is built, the architect’s job is mostly done. He might return to survey how happy the residents are, but that’s about it. Future changes are up to the residents, landlords, and other stakeholders. The architect won’t be able to correct the wrongs other than incorporate these learnings into his next design. On the contrary, a software designer not only needs to design for change, but also change the design.
Software is a fluid medium. You cannot pinpoint a clear demarcation of when it’s completed. It has no end state: after version 1.0, there’ll soon be 2.0; after fixing this bug, more bugs are awaiting. Even if you have no desire to add features and it’s free from critical failures, you still need to constantly keep an eye on it to prevent any subparts from getting dated and as a result leaving the whole thing outright unusable. Softwares will always rest on sand:
However, the more time I spent programming, the more I became aware of the fact that software depends on hardware, and hardware is constantly changing. A program is not like a book or a painting; it requires constant upkeep and adaptation to remain in existence.
...
Essentially, permanent work cannot be achieved on a computer, as the hardware is fundamentally out of the control of the user. No matter what world is created inside of a program, its foundation will always rest on sand.1
The impermanence of software is both a blessing and a curse. On the bright side, the designer can keep working on it after it’s launched. The software will evolve over time, improved and adapted to new needs and situations. Mistakes are allowed, stakes are low, you can put something out there and test it before serious investment. On the other hand, such impermanence also frustrates the makers, for the absence of closure brings a numbness and exhaustion as does Sisyphus’ eternal punishment. The work never ends. Everything you make is temporary, fleeting, and transitional, the stepping stone for yet another round of iteration.
This constant evolving nature means that most of software designer’s work is hardly visible in the public, as in the public there’ll always be only one version: the latest version. All the mocks, prototypes, thousands of commits, are collapsed and abstracted behind this latest version, hidden deep in a folder in someone’s own computer. While a graphic designer is able to show her record covers that look exactly like a decade ago, unlikely can a software designer open up a running program after ten years—dare I say not even five years—and say “this is what I made”. You can still show your design, but it’s no longer breathing. It’s a shedded skin, a buried bone, a forgotten history.
Calling the work done and signing it have moral significance to a craftsman. By putting down the signature he marks his presence with pride: he delivers it, not the snapshot of a thing, but the whole thing as one. In Hannah Arendt’s theory, labor and work are two of the three fundamental human activities. While labor produces goods for life maintenance and therefore is perpetuated by the necessity of biological needs, work provides an “artificial” world of things that transcends and outlasts individual lives. Unlike animal laborans, those who work, the homo fabers, fabricate durable artifacts with their hands:
To have a definite beginning and a definite, predictable end is the mark of fabrication, which through this characteristic alone distinguishes itself from all other human activities. Labor, caught in the cyclical movement of the body's life process, has neither a beginning nor an end.
Recently it occurred to me that the nature of the work we do might actually impact our mode of working. It can affect the rhythm of how we work. For work that has a “definite, predictable end”, preoccupation is possible. You can summon your whole self and grind it through—even if it’s a marathon if we look at it from the span of a life time. You can dash, survive the sprint, rest for a while to replenish the energy, and then prepare for the next round. This kind of “unhealthy”, all-consuming work style is not uncommon among the greatest novelists, painters, and composers.
However, for work that never ends, you will simply burn yourself out like running into a black hole. It becomes necessary to plan one’s energy and approach work strategically. I suspect that’s part of the reason why sustainability and work-life balance becomes critical in the software industry—
Hey! I know the structure of eight hours a day, five hours a week (i.e. the exploitative industrial capitalism) has existed long before software business, but I can’t help but think that the impermanence of software might still make a difference to our work mode. For example, unlike in advertising and graphic design world where the agency/studio partner can handle most of the work for a campaign or an identity, software agency can only do so much for a product. An in-house team still needs to be around for up-keeping and maintaining a long-lived, evolving piece of software. Ultimately, software, like a garden, requires persisting care, attention, and nourishment to thrive.