Though they are wonderful tools that have transformed how we live and work, computers also cause about as many problems as they solve. We can see these problems in the way that work has crept into our private time via email; in the ways teenagers choose to socialize with their peers via text messaging and social networks, often to the exclusion of the world around them (and parents); and in the way that we prepare the written drafts of our work.
In each case, these problems aren’t the result of malicious intent. Rather, they were unforeseen consequences of a transformative technology. When it was originally developed, email was a great way to quickly exchange letters with friends and colleagues. Its original designers never intended it to become the way in which a large number of people organize their daily lives. Nor was the introduction of text messaging or social networks meant to cause teenagers (or adults) to socially withdraw into an online world, but to provide an efficient and convenient way to keep people connected. This is also true in the changes that word processors and communications software have brought to the process of writing.
The Limitations of Word Processing
In the old days, writing was slow and methodical. It involved scratching out your words on a piece of paper, pecking them out on a typewriter, or engraving them into stone. Making changes to your draft was difficult (particularly if you chose to engrave). It required that you rewrite sections that you had already prepared. If you wanted a clean draft, you would have to recopy everything.
But all of the work also had a side effect: it forced you to plan, revise, and rewrite. In the process of re-copying the words, you also had to read them and to ask yourself questions, like: “Is this really what I intend to say?”, “Might this be better structured?”, or “Do I want to use such forceful language?”
Then, along came the computer and it became easy to modify the words on the page. Instead of laboriously copying, it was possible to word process.
In far too many ways to count, this change has been marvelous and miraculous. Instead of wasting effort recopying what has already been written, word processors gave writers the precious gift of time. Time to explore other ideas, to rethink the structure of a draft, or to polish the prose. Unfortunately, though, they also made it easy to be lazy by encouraging processing instead of to writing.
When we word process, it is tempting to sit down and start writing, usually without thinking through questions of purpose, audience, content, strategy, or effectiveness. Word processors provide a beautifully clean draft, which we may be tempted to send off without careful revision. In short, by making things easy, word processors encouraged the development of bad habits.
Even more unfortunately, these influences weren’t just limited to the solitary writer working on his own. They also changed the way in which we collaborate. Gerald Grow summarizes these changes well in his timeless essay, “How Computers Cause Bad Writing”:
Before computers, the usual form of collaboration consisted of dividing up the work so that different authors wrote different chapters; then they reviewed one another’s work. Writing with computers, though, collaborators can enter into one another’s work so readily and revise it so easily that, in effect, co-authors can mutually co-write each sentence.
Grow’s article was written in 1988, and in the past twenty-five years, it’s gotten even easier to enter another’s files and “co-write each sentence.” Tools such as Google Docs even encourage you to work this way by providing the ability to co-write in real-time. It’s not only possible to mess about with other’s words, but as the original author produces them! (I’ve shared my feelings about these real-time collaboration features before, so I won’t do so here.)
There is just one problem with such intensive co-writing, though:
This kind of collaborative writing can be difficult to read. No two writers have quite the same sense about punctuation, tone, rhythm, headings, sentence variation, and the like. In collaborative works, I sometimes find grammatical conventions changing from the beginning to the end of the same sentence–because one author started the sentence and the other finished it.
In the worst cases, collaborative writing becomes a colloid of conflicting styles. In a document I recently edited, one section was written by a psychologist with a propensity for theoretical language, another by a computer programmer concerned mainly with the technical characteristics of machinery, another by a manager recording the history of the project. To complicate things, each author had inserted a few sentences (in his own style) in the midst of the other sections. Every time I reached a new major heading, the narrator changed voice–and the voices occasionally jumped around from sentence to sentence. It was schizophrenic prose, with faults that had been amplified by the easy editing made possible by the word processor.
Put another way, intensely processed documents lead to poor writing and misunderstanding.
Ownership of Ideas
Luckily, there’s a pretty simple solution. Instead of encouraging co-writing, it’s a good idea to have each author own a particular portion of the text. Not only the ideas it contains, but the words used to describe them.
When you give someone the ownership of a section, you provide them with leeway to explore how the material might be presented. You allow them time to say something meaningful.
Unfortunately, we live in a rushed world. Too much writing happens to stringent deadlines and it’s not possible to provide such generous gifts of time to a single person. Co-authors may need and require access to a draft in development. But that doesn’t mean that you abandon the idea of ownership. A single mind working on a particular section is more likely to produce something beautiful than a committee.
At some level, this is intuitive. After all, the jokes about “design by committee” are legion. But it’s also something that you can see quantitatively. Let’s look at one of the best examples available, Wikipedia, the very definition of a collaborative writing project.
Wikipedia articles that are considered to be “high” in quality show a certain pattern of collaboration. For these articles authors more frequently write their own draft, provide their own references, and edit their own work. In comparison, articles rated “low” in quality split the work amongst more people: one group may have written the initial draft, another prompted for references and justifications, a third providing those references, and a fourth editing the prose for clarity and flow.1 In other words, many “low quality articles” are more intensely co-processed.
Now, this doesn’t mean that the entire work should be written by one person laboring in solitude. Rather, that you need to carefully balance the benefits of collaboration with those of cohesion. There is some logical block of material – a section, a chapter, or a part – that exists as a cohesive whole. That is what one author should take ownership of. Once a cohesive draft has been completed, it then goes to others in the group to review. What you want to avoid is the intensive interference that can arise when the draft isn’t ready for editing or feedback.
SVN Locks
Subversion has a feature that can provide for this type of ownership, it is called a lock. A lock (also called a file lock) is exactly what it sounds like. It means that you’re the only person who can commit changes to that file. Commits and changes by other users will be blocked until you release the lock. What’s more, a locked file cannot be modified – meaning that it won’t be deleted, renamed or moved – except by the lock owner.
If you’re using Subversion to write software, locking a particular file is frowned upon. For writing projects, though, it is a powerful way to split ownership amongst multiple authors or editors. Consider the following workflow:
While the initial draft is being written, the file is locked. While others can review the text, they aren’t able to commit changes until the lock is removed. When the first draft is finished, the file is unlocked. If another author or editor will be working intensively on the text, a second lock is placed until finished, and so on.
In addition to enforcing accountability and ownership, using locks for writing projects also provides a technical benefit. Many of the programs commonly used by writers have a binary file instead of plain text file format – this includes Microsoft Word, OpenOffice, and Scrivenener. Subversion works best with plain text. In fact, it is the only file type were file merging is robust. When you lock a file, you prevent conflicts by ensuring that only one person at a time can commit changes. Though conflicts aren’t terribly difficult to resolve, they still require time and effort.2
Creating a Lock
Creating a lock in Subversion is easy. If using the Mac OS X client, Versions, you highlight the files that you want to lock (pressing Shift allows you to select a range of files, holding Ctrl will let you select multiple files at once that are not located right next to one another). Then, you right click and select “Lock” from the context menu.
Verisons will communicate with the server, and place a lock on those particular files. Files that have been locked are highlighted and have a lock icon appear next to them.
The process is very similar for TortoiseSVN. You locate the files that you want to lock in the file explorer. Then, you right click and select “Get Lock” from the TortoiseSVN options in the context menu.
When using TortoiseSVN, other users can see that a file has been locked by opening the repo-browser. The lock status won’t necessarily appear in their working folder, though, unless they frequently check for the current project status via an update. This means that a co-author might not realize that you’ve placed a lock until they have a commit fail.
Checking a Lock Status
To update your working copy with information about what files are locked, you can use the “Check for modifications” option to see what locks you’ve placed. Updating from the repository will let you know what files others have locked.
Breaking a Lock
When you commit changes, SVN will automatically remove a lock that you have on a file. If you’re not quite ready to remove the lock on a particular file, you can uncheck it and exclude it from your commit. It’s also possible to release a lock manually. To do this, you select the file in your working copy and select the “Release Lock” option from the TortoiseSVN context menu.
Summary
Though they’ve transformed the way that we work, computers have made it easy to word process rather than to write. They also have changed how we collaborate. If we aren’t careful, co-authors working on a project may be tempted to co-process the work of their colleagues. This can lead to poor writing and misunderstanding, and for that reason, should be avoided at all costs. Instead, it’s much better to encourage authors to take ownership of a particular section, both the ideas and the words used to describe them.
Subversion has a feature, called a lock, that can help facilitate this. A lock gives one person the exclusive ability edit and modify a file. This preserves the freedom and quiet needed to create beautiful writing. When ready, the lock can be broken and the draft is available to be edited and reviewed by others.
However, while locks are powerful, they are only the first feature that Subversion offers to help facilitate collaboration. In the next entry in this series, we’ll take a look at how the Subversion log can aid better communication.
__________________________
Notes
- To read more about how collaborative patterns influence the quality of Wikipedia articles, see Jun Liu and Sudha Ram, “Who Does What: Collaboration Patterns in the Wikipedia and Their Impact on Data Quality,” SSRN eLibrary.
- We’ll look at how to resolve conflicts in Part 4 of this series, “Dealing with catastrophe.”
Getting Started with Subversion – Part 3.2:
SVN Locks and Idea Ownership is a post from: Apolitically Incorrect. Copyright 2009 – 2010, Rob Oakes.