Cathedral Building and the Art of Writing User Stories
There is no surer sign of tech pretentiousness than talking heads in high collared black shirts, behind thick framed glasses waxing about "changing the world", "inventing the future" or some other boilerplate techno-utopics, while hawking another SaaS tool. The revulsion is understandable: we all know that your ERP-lite piece of software will not really change the world, or bring forward any visions of the future closer.
But still, isn't "building stuff"™ admirable? That high-collared, black-spectacled person is putting themselves out there, taking risk knowing full well they might not have much to show for it. It should be inspiring. But increasingly, that scene is losing its luster. And if there is something wrong with the knock-off man in black shirt, why does the almost religious admiration of Steve Jobs (the OG) still persist?
I found myself thinking about that question while reading this excellent essay about the limits of rationalism and our eroding capacity to wonder. The writer, Simon Sarris, uses architecture as a metaphor for how hyper-rationality disembodies meaning. Cathedrals didn't rationally have to be built the way they were. Cathedrals rationally don't have to exist in the first place. But they do, and we go to see them and be in them, and they "mean" something.1
As ostensibly a professional in another field of building stuff, that made me wonder what is the Cathedral-equivalent in tech products: how do you build products that embodies meaning, rather than just achieve some rational end? That question is especially loaded in the tech industry because it is an industry that prides itself in its rationality. We are too close - historically speaking - to the hyperrational scientific endeavors in electronics, materials, and formal logic that made modern computing possible, that even if you're building the next fart-machine app, you still perceive yourself as "doing science".
Of course, things are changing: there are more practitioners building software today than people formally trained in computer science. There is growing acceptance of software development as a "trade" with "patterns" and "best practices". All terms that allude to tradition, and organic cobbling-together of software, more than to formal scientific enquiry. That's all good and natural and can point to a world where software and tech are truly "human" (i.e. idiosyncratic, full of blemishes, and quirks), rather than industrial (i.e. sterile, formulaic, and repetitive). But while we are slowly breaking away from hyper-rationality in the way we are building software, we are not moving much in changing the way we interact with that software. The proliferation of UX patterns and best-practices, underpinned by - good - statistical analysis of what "works", means that every application today looks and feels the same across use cases, devices, and culture.
You can probably imagine what I am talking about from a UI perspective: pastel colored interfaces, 16x16 monotone icons, round-edged buttons, sans-serif fonts, California-nice copy voice, etc... But it goes to interaction patterns as well: an escape hatch on every screen (cancel/close window), clear signposting, meticulously drawn-out user flows that ensure your journey is always predictable. It is all very.. repetitive.
Is there anything wrong with that?
Green Rooms
Imagine for a second you're sitting in a literal green room. Something like these greenscreen soundstages you see in behind the scenes documentaries. Try to imagine how it feels being there in that minimal, albeit obviously artificial environment. Now imagine being in a natural green room: in the middle of a forest, or sitting in a meadow in your local park. For most people, the natural environment probably feels more relaxing, calm, and even pleasant. It is by definition "natural": our bodies, our senses, and our instincts are well-tuned to the natural environments in a way that doesn't create cognitive loads on the more conscious parts of your brain. You don't really need to spend the mental effort to "see" a leaf. You have a good heuristic that is deeply embedded in your cognitive system over millions of years of evolution that helps you take in the scene, while freeing your mind to wonder. By contrast, the soundstage is deeply unnatural. You're likely to spend a lot of conscious effort making sense of where you are, and less likely to have your mind wonder freely while there.
More importantly, the natural setting has a meaning in and of itself. That meaning is subjective of course: the wonder of nature, the powers of a creator, the smallness of humans, or the marvel of their ability to subjugate nature. But there is "something" to the place beyond its utility as a factory of oxygen and organic material. The soundstage on the other hand, has no meaning in and of itself. It has utility. But your mind is unlikely to wonder or contemplate something bigger, because there is no meaning to contemplate. The soundstage is a tool with a very specific utility.
Today, most of our living environment is digital. Worlds made out of software. I certainly spend more time "in" my Outlook inbox than I do in nature, or on the streets of a busy city. This is more true during the pandemic. Most of us are spending most of our time in hyperrational spaces, completely sheltered from any opportunity for wonder, serendipity, or contemplation. Moreover, the inherent repetitiveness of our interaction with these spaces - there is no equivalent of seasons, snowstorms, or traffic jams to break the monotony - enforces the lack of wonder, serendipity and contemplation as the default condition. In other words, "what has been will be again, what has been done will be done again; there is nothing new" in your Outlook window.
Building Condos
This raises a couple of questions: why did we end up here? And, were we always destined to end up here? The second question is especially salient because the monotony and repetitiveness I described in the previous section are arguably THE point of software. To use the tortured expression, it is a feature, not a bug. Software (Code) is a set of instructions that SHOULD behave in predictable way given specific inputs. And given the nature of digital signal (by which that code is transmitted), it is reproducible with perfect fidelity across space and time. That makes software cheap and effective to run, and underpins the productivity revolution brought about by modern computing.
Fair. But the issue is that of scale. Imagine that building software is like building buildings. Most houses and apartments are in fact similar in essential ways. They are built for similar reasons (to provide shelter) and with similar set of instructions (building "codes"). However, we don't just live in a house or an apartment, but we live in cities and towns. And not every building in the city or town is built for the same purpose, nor with the same rules and sensibilities. Hospitals, churches, police stations, airports and warehouses all have their different internal logic. That variety of purpose, meaning and logic, and the juxtaposition of all, is what makes cities, especially larger ones, wonderous, and serendipitous places. (And when that variety doesn't exist, you end up with infamous modernist urban planning failures like Brasilia).
So the issue is not that individual pieces of software feel like condos. The issue is that all2 software nowadays - that which constitute our lived digital cityscape - feels like condos. It is the lack of variety in how and why software is built that troubles me, more than anything specific to any one particular piece of software.
And the reason all software feels like living in a condo, is because it is built like condos.
My mental model for how most modern software is built is very similar to the real estate development process. In that analogy, the product manager (PM) is the real estate developer: they are deciding what kind of building to build and the general characteristics of it based on their view of the potential customer. Should the building have a few expensive units, or many affordable ones? What kind of amenities? How much retail space? Out of the answers to these questions comes a set of specs of that future building (user requirements in software). These specs are passed to an Architect who translates them into more detailed building instructions, that are passed to a General Contractor (the Engineering Lead in the software parlance) who then tries to build the building (software) to spec, on time and on budget. The PM/Real Estate Developer is responsible for receiving the project and ensuring it meets their initial requirements/specs.3
My intention is not to get into a discussion of the merits of this model, except to say that it feels essential to producing any sufficiently complex software product. Also, there is nothing about this model that leads necessarily to the monotony of software cityscapes I described earlier. You can build a cathedral, an airport, or a theater using this same real estate development process. So why are we just getting condos out of its software equivalent?
The answer probably lays in the communication unit of the software development process: the user requirement.
As a User, I Want Something a Bit Specific, So I can Achieve Something Rational
Writing user requirements - now mostly user stories - is an art. There is no specific formula for what makes a user story “good”. Conceptually, you can make it grandiose: As a Believer, I want to exalt God, so I can achieve eternal salvation. Or, you can make it miniscule: As a perfectionist, I want no brush stroke to exceed 3 pixels in 1 color, so I can establish nuanced distinction between art and photography. Of course both extremes are unusable for modern product-building (although the first one probably describes the design brief of most of the world’s great buildings). A user story that is too high level is said to not provide enough specificity for the development teams (where exactly do you start exalting God?). And a user story that is too specific is almost insulting to the development team, as they should be able to make some decisions on how things are built. Add to that the fact that most (all?) software is built in rational organizations pursuing value-maximizing activities for its stakeholders, and we end up with what I’d call hyper-median user stories:
Median User: You don’t have a user story that starts with “As Bob” because you don’t maximize value by building only for Bob. And a user story that starts with “As a Human” already seems too philosophical for us pragmatic lot around here. Be broad, but not too broad. “As a Marketing Manager”. Good!
Median Definition: As described earlier, you want to be specific, but not too specific on what to build. “I want to show I am producing fancy reports” is too broad, and “I want a 7 column report, with the first column 48 pixels wide and titled ‘Campaign Name’, the second…” is way too specific. “I want a report that shows the ROAS of last 3 months campaigns” seems more like it.
Median Objectives: Saying “So I can prove my value to the company” is too broad, and unsettlingly truthful. “So I can plug the output of the report into another spreadsheet that aggregates campaigns across our region, which then gets aggregated in another national spreadsheet, ad infinitum” is too specific, and also unsettlingly truthful. “So I can reinvest in highly profitable campaign” seems respectfully business-like. Let’s go with that.
So while…
As Bob, I want to show I am producing fancy reports, so I can prove my value to the company
… would be refreshingly human (and can lead a creative development team down some paths I’d love to see), we end up with …
As a Marketing Manager, I want a report that shows the ROAS of last 3 months campaigns, so I can reinvest in highly profitable ones
.. which is.. umm.. unremarkable.
That hyper-median quality of the user story directly leads to the sameness of the software cityscape in a couple of ways. The obvious one is that every product manager building an advertising reporting feature, and operating in a similar organizational environment, will essentially write the same user story.
The less obvious way has to do with the constraints of the software development process. Because time is the most precious resource (engineers and product managers are typically salaried, so the development cost linearly increases with time), development teams have to build the user story in a time-efficient manner. That almost always means you can’t go beyond what the user story specifies. You can’t go bigger. That’s “scoop creep” and over-engineering. But you also can’t go smaller. And what I mean is that you don’t want to spend too much time in the tiny details of the UX of what is being built. The most efficient way is to fall on existing patterns and best-practices. Which usually means: white backgrounds, rounded corners, California-nice copy, sans serif fonts, etc…
All of this of course is gross simplification, and some teams occasionally manage to break away from these constraints. But they almost always do it consciously. They decide that they will purposefully deviate from UX standards, for example. But these examples don’t negate the existence of the hyper-median pull. If anything, they prove its power.
Tech Cathedrals
Which brings us back to the offhand reference to Steve Jobs earlier in the article. Frankly, I don’t know that much about Jobs. I have read a few pieces, watched a few videos, and heard many anecdotes here and there. I haven’t read any biographies, or memorized his “stay hungry, stay foolish” speech. And yet, I kept coming back to him when contemplating that question of: where are the tech Cathedrals? Products that break the monotony of the tech cityscape, transcend their utility to create some meaning in, and of themselves, and in the process allow your mind to wonder, and contemplate. The conclusion that the iPhone is probably one great tech Cathedral is simultaneously humdrum and sacrilegious.
On one hand it is obvious that the iPhone means something. It is like saying the Catholic Church means something. Everyone knows about it, everyone has seen an iPhone. Its impact on the development of the internet and the world economy in the past 14 years is not even worth pointing out. Its obvious.
But, Cathedral? Isn’t the iPhone just another consumer gadget. It reeks of materialism and utilitarianism. It hardly invokes the transcendence of a St. Marks or a Hagia Sophia. And, yet I’d argue it shares with them an important feature: it was built for something beyond its utility; it sought to convey a certain meaning that mattered to it’s creator. While the meaning of the aforementioned Cathedrals may have been about faith or power, a lot of the iPhone (and the predecessor Mac) is about the personal atheistic of Steve Jobs. Anecdotes abound:
In reaction to a redesigned feature he showed the late Apple CEO, the source says Jobs felt his design was too minimalist. “He was like, ‘I want it to look like a Chiclet; I want to be able to lick it; I want it to be like glass on water,'” the designer recalls. “He wanted to create this feeling of a really beautiful, physical gem-like element. 4
.. or his recollection in the famous speech of why we ended up with typography in personal computers
Reed College at that time offered perhaps the best calligraphy instruction in the country. Throughout the campus every poster, every label on every drawer, was beautifully hand calligraphed […] It was beautiful, historical, artistically subtle in a way that science can’t capture, and I found it fascinating […] If I had never dropped in on that single course in college […] personal computers might not have the wonderful typography that they do. 5
That the iPhone ended up being this world-defining product has a lot to do with great engineering, creative marketing and incredible luck. But a big part of its salience; its meaning, has to do with the fact that you couldn’t have conceived of it in user stories. At least not the user stories we write today. The pleasing smoothness of a Chiclet, or the historicity of serif fonts can hardly be conveyed in that format. But that format is the language we use to build our software cityscape, and that language actively chases away transcendence.
As a Human, I want to be inspired and surprised, so I can contemplate the wonder of life.
I am criminally over-simplifying his argument, so go read it.
With one notable exception - Video Games. I hope to come back to it later.
Of course this is an imperfect analogy, and the interaction between PMs and Engineers - for example - is very different than a developer and sub-contractor relationship. Also, I am aware of the sensitivity about hierarchical descriptions of software teams. A sensitivity that is usually a response to a description of Engineers as automatons dutifully coding someone else's requirements. But I think that sensitivity comes from confusing roles for identities. In my description the PM and Engineers are roles, not identities. In most real teams - especially smaller ones - a few people are both defining what to build and how to build it. Most of the time they are engineers by training. But that doesn't change the fact that when they are deciding what to build and why, they are playing the PM/RE Developer role.