A recurring annoyance to me is the incessant use of team folders to share data in teams, projects, or companies—in particular where those with little knowledge of computers make the decisions.
There are cases when this is quite in order, e.g. when a large file should be distributed once to a group (a one-off distribution is usually a good task for email, but email can be highly wasteful when larger files are concerned).
However, most uses are poor—and typically one of two or three roads (or a combination of these) should be chosen. These are discussed below.
As to the reasons, I suspect a mixture of ignorance and a (usually) misguided fear of a learning curve. While e.g. becoming an expert Git-user takes time, reaching the level to merely replace team-folder uses is far easier. (A case can be made, however, against combining too many tools in the same project/company/whatnot.)
By “team folder” I refer to a folder (possibly including sub-folders) in common use by several-to-many individuals and accessible from more than one computer for the purposes of collaborative work on a set of documents and/or for data exchange (and possibly some other uses too). This can include “shared folders” and “network drives” under Windows—and, indeed, here we find the typical uses. Similar mechanisms, however, are available elsewhere too.
Not included are e.g. network file systems (or parts thereof) mounted on more than one computer for the purpose of programmatic access or to allow a single user access to his own documents from these computers.
Use of a version-control tool like Git or Subversion:
With a small initial overhead, it becomes possible to share the data very easily, changes are protocolled, earlier versions are easily retrievable (without having to resort to filenames like [document name]-v1.1, [document name]-v1.2, etc.), and the risk of concurrent changes being lost is (almost) removed—in particular, as there is always a “canonical” version to refer to in the corresponding repository. Notably, most major tools have a variety of access possibilities, including command lines, plugin-ins for the Windows Explorer and various IDEs, and a web-interface.
The only major disadvantage with this setup is that the support for different access rights for different users is often highly limited and that it might be necessary to have several repositories for different groups of users. However, with who-changed-what-when protocolled, the potential damage through write access is highly limited—illicit changes are easily revoked and the perpetrator can be held accountable.
When it comes to data where some type of history is needed, where “branching” or “tagging” is a topic, or similar, as with e.g. source code, some type of such tool is virtually mandatory.
Use of a wiki:
Wikis provide the additional advantage of allowing for easier grouping and structuring of information (e.g. as one page linking to further pages and assorted documents) and come with built-in editing capabilities that make many (MS-/Open-/whatnot) Office documents unnecessary.
Indeed, the idiocy of grabbing MS-Word to write even a ten-line document that would have been better kept in plain-text is another of the greater annoyances with unskilled computer users.
Unfortunately, the version-control capabilities are weaker (but usually still vastly superior to those of a shared folder!), with lesser possibilities of programmatic access and the risk that some data (most notably, attached documents) do not underlie version control. In addition, in a potential disadvantage even to shared folders, the many (Linux et. co) resp. few (Windows) tools that work on batches of files in the file system can no longer be used without additional manual effort. (However, with luck, this is a time-limited problem: If wikis provide WebDAV or some similar means of access to their contents, a natural future step, they can be mounted like ordinary file systems.)
For sufficiently structured data and with the right circle of users, the use of a DBMS is a strong option. Unfortunately, this option requires considerably more from the users and is a poor choice for e.g. textual information. Further, versioning is rarely available “out of the box”.
A particular interesting case is the use of tools like sqllitew, which make it possible to keep small databases in ordinary files while still allowing SQL-based access without the overhead of a conventional DBMS. These files, in turn, can easily be put in a version-control tool or a wiki.
Excel is somewhat similar; however, the treatment of data and data access vs. display of data, as well as a number of internal limitations, makes Excel a poor choice for most “serious” databases.
The use of various Office documents together with tools like the above often, unfortunately, leads to a reduction of usefulness. For instance, most version-control tools are unable to show the changes from one version of an MS-Word document to another—but, unlike a shared folder, will still be able to provide the older versions of the document.
Then again, the problem is not with the version-control tools but with MS-Word et co. I have long recommended that such formats be avoided: Wikis, LaTeX, structured XML documents, whatnot, are almost always better alternatives for professional use.
For all practical purposes, team folders are nothing more than unversioned heaps of documents—obviously weaker than other alternatives. Further, they often bind to a particular platform, bring unnecessary security risks (including through accidental deletion and through incorrect user rights), and regularly cause problems through documents being inaccessible to those who should access them (either through incorrect user rights, again, or through an author making the incorrect assumption that readers will have access rights on a folder where they, correctly, do not).
Even calling a team folder a poor man’s wiki or a poor man’s version control would amount to flattery...
Correspondingly, they might be adequate (on a “least path of resistance” basis) in a short-term and ad-hoc amateur setting, e.g. two students collaborating on a very small project, a family having joint access to vacation photos, or similar. In a professional context, however, they can only very rarely be justified—their presence is typically either a sign of decision makers not knowing better or of pure laziness.
This text was originally written in 2012, when various “cloud” solutions were much rarer. By now, 2024, this is very different.
Whether similar remarks apply to these will depend on the interface used and a blanket statement is not possible. The range of services commonly labeled with “cloud” is simply too large, extending from primitive online folders to complex GUIs and web services.
I do strongly advice against the use of cloud solutions in general, however, if for reasons that are not always on-topic for this page, including a greater risk of data leaks; a greater dependency on an Internet connection; a reliance on a service provider (of unknown mentality, competence, long-term reliability, etc.); common problems with moving data elsewhere, making backups, whatnot; and similar. (A use of own and local servers using self-administered software, as opposed to a third-party service, can reduce such problems.)
The following is an automatically generated list of other pages linking to this one. These may or may not contain further content relevant to this topic.