Home > Other > Software project configuration in your code repository

Software project configuration in your code repository

Mostly, I try to stay out of religious discussions. I’m not talking about Buddhism vs. the Mormon belief, I’m talking about discussions in which it’s been recognized that there really is no right side because the opinions of the debaters are based on belief.

For example, which is a better programming language, Perl or Haskell? Ruby or C#? I don’t care! Whatever will get the job done and what the project leader wants. I have my own personal opinion, but when it comes to work, I try to do what I get paid for. Sometimes, in the best situations, I’m being paid to make work decisions on the basis of my own personal experience and opinions — but that’s not always the case.

However, I must admit, there’s one thing that really, really irks me: project configuration files being stored in the SCM system a.k.a. your source code management system — CVS, RCS, subversion, mercurial, git: see above, I don’t care, etc.

When someone starts putting a .project file and a .classpath file and in fact, any file that begins with a “.”, then that means two things:

  • The person committing those files to the repository is basically saying: here’s how you need to set this project up (with regards to the IDE and other tools you’re using to code).
  • I either shouldn’t use the tools I usually use on this project or otherwise, I have to make allowances for the weird ways that the tools I use are going to react, because of said files.

There two things I’d like to explain and mention:

  1. Here’s what happens to me when you commit (project) configuration files to the repository:
    • I start up my IDE and look at the project. In the course of working on the project, those configuration files are going to change because I use different tools than you do!
    • When I’ve already commited my changes, and sometime later I go back to look at my project. Only, then I notice that there are things I haven’t committed — oh yeah.. my tools modified the project configuration files.
      • The thing is, unfortunately, I care too much about having my colleagues be productive and I know out of experience that committing project files is usually a religious issue. So I just work around it.
    • Otherwise, I’ve been forgetful enough that I’ve actually committed your project configuration files. And then you update your copy of the project and most likely update and recommit the project configuration files.
      • And at this point, we’re both just wasting time when we could actually be doing more productive and meaningful things. This is why I don’t do this.
      • I’ve never committed over project configuration files, but the older and less patient I get with the youth, the larger the chance is that this will happen. [Oh no!! Please don’t, mriet!!]
    • This might not seem like a big thing but it is when I’m spending my whole day on a project and seeing the results of this problem every hour. It’s not the time — it’s the energy it costs me to suppress my irritation at the thoughtlessness of the developer who did it.
    • Okay, that’s a little over the top. Hopefully it was a good example of how much energy this kind of thing costs me.
  2. My work is to produce software. It’s a little more than that, but that’s what it comes down to, regardless of whether I delegate tasks to other developers or not.
    • Like any professional, I have a personal preference for the set of tools I use in my profession. I use the tools I use because they help me do my work more quickly.
      • I use a vi plugin in Eclipse and regularly get bizarre looks for this. It helps me work more quickly and that’s what it’s about!
      • When you are working with me but on something that doesn’t affect my work, then I don’t care! It’s as soon as you start to impact my work that we have a problem.
    • When you start telling me how to use my tools — I’m not talking about advice, I’m talking about telling me (see above said files) — you’re impacting how productive I am.
    • Is telling me how to use the tools I use really worth reducing my productivity? If it is, I’m curious as to why.

In short, don’t do this. You are not an island — and if you are, good luck getting interesting work. Everyone knows this, but the most important qualities of modern (software) developers is how well they can communicate and how well they can work in or lead a team It’s a big world, and it’s only getting bigger: getting along with the rest of the world only helps.

Advertisements
Categories: Other
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: