Work Life: Windows Shared Folder

Sometimes you do not have control over how teams manage their files. Here are some of my thoughts when they use Windows folders without source control.

Cons

Version Control

One common occurrence when you have multiple people working on the same files is that someone may override another person's changes. This could occur maliciously or innocently. There is a good chance that if multiple people are working on the same file that they replace the files around the same time. The last person may not have known the file was just updated during the time they were uploading the changes.

Folder Structure

Unless there is an enforcer, everyone has their own breakdown on how data should be broken down or sorted. For example, internal processes could be broken down as Internal > Processes for someone that deals more with internal team vs external teams or Processes > Internal for someone that deals with processes vs templates vs administration.
This process breaks down further when someone is tasked to upload a file to the shared drive without clear knowledge on how all the folders are structured. Thus oftentimes, the person will just create another folder in what they think would be the best bet. A clear indication of this is when you find a lot of folders that have a single file in it.

Duplicate Files

Due to the cons of folder structure, there is also a good chance that users upload the same files in different locations. Although this is also possible in other file sharing solutions, most of the other solutions do have search which help reduce this possibility. Microsoft's search within network folders is less reliable than local files which also is not always reliable.
This makes it difficult for a new user to know which is the official file to use (assuming the person finds both files).

Naming Convention

Due to the above limitations, people have come up with different workarounds. One of the most common ones is to append new, updated, backup (bkp), or a date. After several versions, more files are stored where most will never be used again. By the time that such files may have use, there will be confusion if 'new' is newer than 'new2' or 'new new' or 'newer' or 'newest'.
Sorting is also quite difficult especially if a date is used. Most people like to use the MMDDYY or MMYY or MMYYYY. When the dates spans multiple years, the files no longer sort in chronological order because alphabetically 02.2014 will come before 03.2013, where it should be 03.2013 then 02.2014. Sorting also becomes even more difficult when different delimiters are used: periods, dashes, subscores, spaces.
There is also confusion with MMDD with small values because it is not intuitive whether the file is MMDD or DDMM or MMYY (for example 0102). The problem with MMDDYY is similar in that it can be confused with YYMMDD, for example 010203. The year will eventually need to be appended because theoretically 50% of new files will be created in the second half of the year and 25% in the last quarter. Continuing the same process will likely extend to the following year. Now, the user can either update all the files or they create even more subfolders which is just more overhead or clutter the shared drive.

Best Practices

These are some practices that I like to use.

Dates

I recommend that people use YYYYMMDD if they have to use dates. There are two benefits to this. First, it is clearer that the first part is the year (primarily because the years will never be less than 1200 and months will never be 20+). If for some reason the date is for earlier than the 13th century, use some sort of delimiter. A delimiter could be useful in either case and should be decided by the team. Removing the delimiter is useful in reducing file length which some systems still have issues with. Second, the file system will naturally sort pseudo-chronologically (pseudo because it still sorting alphabetically).

File Backup / Version Control

I recommend that you make a copy of the file you are going to edit then rename the file with the current date (YYYYMMDD). When ready to publish to someone else, copy the file again but rename without the date (assuming you do not want to include the date for aesthetic). This will prevent someone from accidentally click save and override changes by accident. This also prevents file locking issues (use your userid if someone else is modifying the same file). And this is somewhat like version control. If additional backups are needed in the same day, unique identifiers can be added to the end of the file. They should avoid using adjectives, preferably another count for example 20140101.01 or 20140101.01.myid (to identify who owns this iteration). A policy should exist that these exceptions should be deleted at a future date to cleanup and declutter the shared drive.

Folder Structure

There is little that can be done to enforce folder structure especially when managing multiple environments and multiple teams. Ideally, a desired file can only go into one folder or the other, for example internal or external, process flow or templates. This way of thinking would cause increase levels of subfolders which is also undesirable. A user should be able to navigate to their desired files around 3 levels. Any more, the folders have to attempt to be as exclusively mutual as possible.