2

I'm the sole software developer on a team of graphic designers and 3D artists. Our guys are amazing at producing creative works, but most of them are having trouble following file naming conventions. This is a headache for the manager when issuing reviews to the client, and also to me, since consistency in the files makes my development much smoother.

Our conventions are as follows:

  • Folder names should be in UPPER CASE
  • File names are in Title Case, apart from any included acronyms, which are UPPER CASE: e.g. "SICEEP Aerial.max", or "Townville Metro Aerial 01.psd"
  • All folder and file names use spaces, not underscores
  • All working project files (like .max files) should be prefixed with an acronym of the project name

There's more conventions specific to the design software used, e.g. what files need to go under the "Photoshop" folder, how to best name modelling files, and where to put outgoing files. All in all the conventions are about a page.

The comanager has sent out a few reminder emails about these conventions, and our last measure was putting a paper stand with the conventions on each team member's desk. The files are still named haphazardly and in the wrong place. My manager says the team just aren't reading the conventions. If it helps to know, the company culture is seriously relaxed and very blameless.

Does anyone have any ideas or advice?

closed as off-topic by Lilienthal, gnat, Chris E, Joel Etherton, jimm101 Sep 23 '16 at 15:26

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions seeking advice on company-specific regulations, agreements, or policies should be directed to your manager or HR department. Questions that address only a specific company or position are of limited use to future visitors. Questions seeking legal advice should be directed to legal professionals. For more information, click here." – Lilienthal, gnat, Chris E, Joel Etherton, jimm101
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 5
    Introduce some accountability, you tried being nice already and it didn't work. – Kilisi Sep 23 '16 at 2:16
  • 3
    "Our guys are amazing at producing creative works". You really expect that type of person to conform to a standard. That violates their being. Just reject the creative writing until they conform and have hissy fit battle (hissy is also part of the being). Or just accept. Really is caps on a folder all that critical. If there is file on the end I am good to go. If file name must be prefixed with the name of then you have too tight of coupling. From what I see process is the hissy. If your review process driven by naming convention then OUCH. – paparazzo Sep 23 '16 at 2:46
  • 5
    @Paparazzi that's a ridiculous amount of unfair stereotyping. – user42272 Sep 23 '16 at 4:20
  • 2
    Your system sounds insane. Why do you even care about letter case? Why do you need prefixes when you presumably have a folder structure? That aside, this is on your manager to solve, not you. Any action you take (such as refusing non-standard files) would need to be approved by him first. VTC as part of company regulations that you have no control over, check with your manager. – Lilienthal Sep 23 '16 at 6:42
  • 2
    @KaterinaB. your confentions are insane. FIX them and don't do it alone. – Raoul Mensink Sep 23 '16 at 7:53
12

Those conventions sound really odd to me. One, I've already forgotten them. Two, spaces in filenames and folders can be very hard to work with. Three, case sensitivity in directory names is usually avoided. Basically this is all to make scripting and organizing easier, but your convention seems to do the opposite.

They might just be used to living and working in a place known as "the rest of the world," and really hate your conventions and so far the best way to deal with it for them has been to just ignore them. It sounds like this has been effective for them so far.

You should probably find out why they prefer not using the conventions and why they don't. Actual communication will go a lot farther than more signage.

  • If you really want to enforce them then think about getting Source Control. You can check file naming conventions very easy before committing into the repo. You can reject it with an explanation without having to do anything beside a pre commit hook. – Dan Sep 23 '16 at 13:58
  • @Dan that sounds like it would escalate tension between teams, not resolve it. – user42272 Sep 23 '16 at 14:25
  • While I agree fully, I don't think this is actually an answer to the question. – simbabque Sep 23 '16 at 14:28
  • @simbabque It's better to address the actual problem, which, in my view, is an evasive response to terrible conventions and a lack of communication about why they don't use them. Any advice proposing methods to coerce the other team would probably be terrible. Called the XY problem in SE . – user42272 Sep 23 '16 at 14:34
  • 1
    Again, I agree. ;) – simbabque Sep 23 '16 at 14:35
9

This is a headache for the manager when issuing reviews to the client, and also to me, since consistency in the files makes my development much smoother.

Sounds like a fairly one-sided benefit so far.

Have you asked them why it's so hard? Do you have regular team meetings where you can air this and discuss the implications rather than sending emails and paper stands (whatever they are)?

  • What does it matter to you?
  • Do they realise why it's important to you?
  • Exactly what are the consequences?
  • Can you change?
  • What does it matter to them?
  • Do you realise why they don't care or the effort caring takes?
  • Exactly what are the consequences of them changing/not changing?
  • Can they change?

Sounds like a there's a pretty major gap in communications and knowledge of overall process flow. A simple, semi-casual get-together might fix that without too much angst.

3

This is something that should really be addressed at the management level. If this is indeed an important requirement, and people keep ignoring it despite efforts to remind people and communicate the importance, then there should eventually be some sort of consequences for not doing things correctly.

But of course you are not the manager, so you are not able to change that. Here are some things which you might be able to propose from your position:

  • Simplify the conventions. A naming convention that needs a page of rules is over the top. I see no benefit from this complexity. As a developer, you only care about consistency. I doubt the clients care about the capitalization of things, if they see the files (inconsistency would look messy but otherwise, why would they care?). I would propose a new convention that is a sentence rather than a page, such as "File and folder names will be lower case with spaces rather than underscores." A logical directory structure should probably be another sentence or two at most (unless you are working on a huge, complicated project).
  • Automatically rename things to meet the convention. If the above doesn't work or is not possible, why not a simple script that automatically renames all files to meet the guidelines? This should only take a couple of hours to bash out--this isn't very complicated. Problem solved.
  • Refuse to work with files in the wrong location. If X files are supposed to be in directory Y, then your software should only look in directory Y. Any time you don't find the appropriate file, then go back to the original creator and ask them to put it there for you (rather than moving it yourself).
  • I feel like what you are referring to as "actually being managed" just amounts to "textbook bad management." You can elaborate though. – user42272 Sep 23 '16 at 14:24
  • @djechlin, I simply meant that there should be some sort of consequences if people continually fail to follow a policy. I don't think that is bad management. (Of course there is much more to management than that, but my answer wasn't really about management anyway. The opening statement was a bit too flippant so I have revised it). – user45590 Sep 23 '16 at 15:25
  • (1) I'm in favor of. (2) and (3) I think run the risk of passive aggressive without proper communication or getting buy-in from the target team. (2) in particular may break their tooling or they may clobber some other file with the other name. Just from a software engineering standpoint more complexity = less transparency and more mistakes. I kind of covered this in my answer so I won't +/- vote here though. – user42272 Sep 23 '16 at 16:42
0

First, have you talked to them about why the conventions are needed and what problems it creates when they aren't followed? People don't follow rules like this unless they understand why they are needed. If you have flexibility in how the rules are set up, then sit down with them and create a better naming standard that everyone not just you can live with (and, really, lose the spaces in filenames!!) People do better with rules they had a hand in developing. If there is no flexibility due to the rules being a requirement of some third party software, then explain that.

But right now there is quite literally no reason to follow rules they didn't choose and regard, most likely, as stupid. They get no benefits and there are no consequences for failure to follow the standard. Why on earth would anyone choose to follow those standards under those conditions?

Next, once a standard is agreed to by everyone, simply reject the work until it is complete and complete includes properly named. If they miss a deadline because they didn't name the files properly, then they missed the deadline and should be the ones to take the heat for it. There must be consequences for failure to adhere to the standards or they are simply recommendations not standards. Laid back, fun workplaces with no management are ineffective places to work.

Not the answer you're looking for? Browse other questions tagged or ask your own question.