The Myth of Software Collaboration
Tags: apps, ux, knowledgework, softwaredevelopment
Published: 2019-08-16 14:53:01

---
title: The Myth of Software Collaboration
description: Exploring why our systems feel lonely
published: true
tags: apps,ux,knowledge-work,software-development
canonical_url: https://medium.com/dealeron-dev/the-myth-of-software-collaboration-599ce6d5c21e
cover_image: https://thepracticaldev.s3.amazonaws.com/i/dv0gx7pl2jaopp2danq1.jpg
---

_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

![](https://thepracticaldev.s3.amazonaws.com/i/a3xhi54ihce6zvv81tty.jpg)<figcaption>Photo by <a href="https://unsplash.com/@heyeje">Heye Jensen</a></figcaption>

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](https://blog.trello.com/why-context-switching-ruins-productivity) 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.

![](https://thepracticaldev.s3.amazonaws.com/i/2av8x1nbfsa1v6m5zpr7.png)<figcaption>Photo by <a href="https://unsplash.com/@hikendal">Kendal James</a></figcaption>

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

![](https://thepracticaldev.s3.amazonaws.com/i/kci28l2a7kmzdgvcad06.jpg)<figcaption>Photo by <a href="https://unsplash.com/@leliejens">Jens Lelie</a></figcaption>

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.

![](https://thepracticaldev.s3.amazonaws.com/i/82t4ed2ck1wge61pt5s8.png)<figcaption>Photo by <a href="https://unsplash.com/@rawpixel">rawpixel</a></figcaption>

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)](https://homes.cs.washington.edu/~mernst/advice/github-pull-request.html). 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.

![](https://thepracticaldev.s3.amazonaws.com/i/s2wg5b45pen1jnrah25v.png)<figcaption>The pull request icon</figcaption>

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

![](https://thepracticaldev.s3.amazonaws.com/i/flfeqbfg3cdy34c4sf5v.jpg)<figcaption>Photo by <a href="https://unsplash.com/@d_mccullough">Daniel McCullough</a></figcaption>

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](http://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](https://homes.cs.washington.edu/~mernst/advice/version-control.html#repos-and-working-copies). 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](https://dev.to/dealeron/finding-humanity-in-software-5a45).

* * *

<sub>*Cover photo by <a href="https://unsplash.com/@grakozy">Greg Rakozy</a>*</sub>