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.
