The Myth of Software Collaboration
Exploring why our systems feel lonely
For all the wonder it brings to the world, contemporary software has yet to deliver on the promise of working together. Applications are most often solitary experiences, rarely connecting users directly. This yields a kind of serial collaboration, each of us making decisions in isolation, then sharing. We act, we react, but we don’t interact. Software’s evolution lies in finding each other amid the tech.
The single biggest problem in communication is the illusion it has taken place. — George Bernard Shaw
App-artments
The dominant UI paradigms put us in functionally identical apartments, adjacent but separate. We see the effects of others, yet never quite encounter them. Even on the same page, working with the same data, our presences are mutually exclusive. How do we work together when we exist apart?
Other apps, of course! Communication is just a context switch away. Pack up that line of thought and venture out into a neighborhood of options. Fire off an email, IM, text, post, ticket, comment, etc, beckoning someone else to make their own context switch and reply. After a short time we switch away, then back again when they do respond.
This is not a recipe for focused, fruitful work between users. It imparts friction on the simplest of conversations, thrashing the attention of participants and fragmenting the computing experience. We are left to weave the disparate information into a cohesive whole, one we cannot represent anywhere but our minds.
The result is a baseline cognitive load that impacts our effectiveness. Those we consider computer people are better at shouldering the burden. Combined with the illusion of parallel experience, it is no wonder we generally consider software frustrating and foreign.
Decisions, Decisions
To understand our predicament, we must look to the core abstraction of knowledge work: the decision. A decision is a statement of fact, a conclusion reached after considering the available data and possible outcomes. Each one adds information to the world, which in turn shapes future decisions.
This cycle fuels information systems, accreting into a body of work whose health reflects the quality of its decisions. Thriving systems provide rich, relevant context at the right times. They connect stakeholders and guide their efforts, refining decisions to high degrees.
Struggling systems look a lot like app-artments. They rely on people to maintain their own context, providing little if any at decision time. Interaction happens elsewhere — the system is but the last mile of a longer journey. Decision quality becomes bland, heavy on the what yet light on the why.
The primary difference is the potential for insight. More eyes on better data makes a more thorough analysis. Ideas and concerns get considered from various perspectives. Problems and opportunities surface earlier, broadening the horizons of the solution space. A positive feedback loop emerges that improves quality over time.
There is an irony in decisions being this fundamental to knowledge work, yet software tending to isolate us when we make them. How do we turn these lemons into collaborative lemonade?
Sharing is Caring
Collaboration creates shared understanding through shared decisions. We work toward common goals and build rapport as a side effect. Software misses the boat here; decisions usually take effect immediately, with other people becoming aware then or after. There is no place for working together beforehand. This is not sharing, but broadcasting.
Software developers have a nifty concept called a pull request (PR). Instead of applying changes instantly, we open a PR with our proposed work. Other contributors review and discuss it before it takes effect. The author incorporates feedback, repeating the process until the work is just right. Only then do we promote it to the live system.
The product of that interaction is not attributable to a single individual. Each person influences the result, crafting a shared understanding along the way. All involved are well-prepared to tackle the next decision. This is the material from which strong teams are made.
Unfinished Business
There is another irony in developers wielding such a powerful concept, yet omitting it from the software we write. This small tweak, inverting the flow of work from push to pull, has a profound effect on how we collaborate. The system becomes where decisions happen, not just where they get recorded.
For example, I wrote this article using the medium.com tooling. After submitting to a publication, I received some feedback, discussed it, and made adjustments, all right in the draft. There was no need for a second communication channel, or the context switching it would imply.
However, this is rare. Software in general lacks drafting processes, offering no middle ground between saved and in effect. If it closes, my work likely closes with it. Validation also interferes— we can’t save anything if we don’t know all required fields, or only have part of a phone number.
We need a first-class understanding of work in progress. Here again we find developers hiding something: the working copy. This personal line of work is persistent and lenient. Only when submitting do the usual rules apply. We have space to occupy while working out the best form of a decision.
Drafting leads to more hospitable software, inviting users to get comfortable and stay awhile.
Wrapping up
Contemporary software attempts the illusion of parallel experience, but tends to feel burdensome and counterintuitive. Improved decision quality brings an improved experience, benefiting from richer context and more minds. Collaboration arises with shared goals, orienting teams around decisions before they get made.
We can facilitate these processes by looking to our own workflows. Pull requests and working copies, incorporated into design, may lead to interesting and novel user experiences (as I found writing this article).
Enabling users to draft, review, and publish decisions is another way we can find humanity in software.
