“Imagine a software development task: some sort of requirements and specification including performance goals and perhaps a platform and programming language. A group of developers head into a vast workroom. In that room they design and code — and sometimes they discover they need to explore the domain and the nature of potential solutions." (from the call for papers)

OK, the group of developers head into that vast workroom. Requirements and specification are complex, the programmers are more than a handful, and work division is all but self-evident. In particular, even though they can agree on an initial work distribution, there is no clear module structure, and stable interfaces yet need to emerge.

So, what do they do? After an initial stand-up, they open their laptops and start their editors. Of course, they use ver- sion control, and yes, version control is file-based, so they edit files, even if they fancy their projectional editor. They use a build tool, too, so from time to time, they integrate their work. As always, integration uncovers inconsistency, and requires changes in various places. That’s when the initial excitement starts fading, and the sobering pains of collaboration take over.

“Hey, Ada, I need to change the signature of this method C.m() you have been working on. Any problem with that?” asks Ben. “No” replies Ada, “but let me finish my working on method C.n first. I’ll let you know when I’m done!” Of course, Ben could have just changed the current version in the repository, and let Ada discover and merge the change after her (vain) attempt of checking in her own changes (a strategy referred to as optimistic locking), but Ben knows the pain of merging himself, and considers it impolite to rush in his changes and leave the cleaning up to others. Ada on the other hand knows that she has the habit of working on many files simultaneously, and acquiring a write lock on each of these les (a strategy known as pessimistic locking) will stall the progress of others, and will make her appear uneasy to work with. So, Ben and Ada, like the rest of the team, coordinate their edits using informal conversation on Slack, improvising, for most parts, pessimistic locking (“Anyone working on file C? If not, let me have the lock and I will let you know when I’m finished.”), using optimistic locking mostly as an indicator that collaboration went wrong (“Who changed file C I’ve been working on for the past three days? OK, I’ll send you my copy so that you can do the merging!”). Although this informal conversation may be good for the team (if only to keep everyone updated about progress and responsibilities), it seems to be primarily a consequence of inappropriate tooling; specifically, of a technical dependency on les and thus on an artifact of operating systems that is foreign — at least as a language construct — to literally all modern programming languages.