I just found out that my workplace has installed software that analyzes source check-ins for such things as who checks in the most lines, when they mostly do their check-ins, which files have the most changes, etc. I'm a bit concerned that this has something to do with the economic situation, and they are looking for a way to measure "developer productivity".
Does anyone have any experience or advice for dealing with this unsettling situation? Just ignore it?
First of all, I would ask how the information is going to be used and what the goal is in collecting those metrics.
There is some values in computing some metrics on the code to get a feel for the areas of the code that may need to be refactored. I have personally used some free source metrics tool to analyse customers' code and make recommendations.
Of course, using this information to measure individual productivity is not a good idea.
You should determine:
All those elements should give you a better grasp on the intent behind this process.
I wouldn't ignore it completely, but unless you are concerned about your volume/quality of commits, you really should have nothing to worry about.
Having some experience with ohloh.net, I've seen how some developers can look really good by committing hundreds of lines of new code vs someone who is maintaining code with a handful of line changes, and obviously we are talking apples and oranges here. Sure, they could have a metric for add vs update commits, but that all depends on who is assigned what, etc, etc. Had one developer who would sit on code for weeks or months at a time and do these MASSIVE commits, totally would throw off the "when you deploy metric".
Another issue with source control metrics is when you add SCM to an existing project way after development or deployment. I've had coworkers work on a section of code that was never version'd and they were responsible for getting it all added, and to someone not familiar with the life of the project, would think this developer had written all the 'initial commit' themselves when this was not the case (ok, it was my code, i admit it. lol)
Just make sure you Q/A your own work well and people don't have to clean up after you.
All the places I've worked with code analysis like this it was just another tool to get software quality up. I wouldn't worry too much about them sacking you on the basis of what the tool is telling them. My approach would be to ask around, ask your boss - it you're not working in a viper's nest you should get some re-assurance.
Good luck, BTW good use of SO must be a good positive in your favour.
Don't ignore it. Get educated. How is it being used? How can you influence how it is being used? Do some research and make some suggestions of your own on how to use the tool to the benefit of your team. What do you think your team should be measuring and improving?
If the goals and usage are bogus and counter-productive, call them out (respectfully). You can find plenty of references to how software measurement is used poorly. Don't make it just about your own personal fears of what it might mean for you and the team, use the data that your forebears have already contributed on the subject.
This could be a great opportunity to show some leadership within your team.
I'm going to contradict most of the other posters here: you should completely ignore it unless and until it becomes an issue. Unless you have good reason to assume that it is going to be used as an evidence collection tool, don't give it a second thought. You have more important things to spend your mental energy on.
I've used a tool that produces such numbers (FishEye), but the fact that it does so was incidental; its chief purpose is as a code inspection/review tool. The check-in data, as they apply to a single developer, can actually be quite interesting to that individual: for example, knowing the rhythm of your work might help you plan your week.
If it does become an issue, then you should follow the guidelines in some of the other answers (refer your colleagues to articles on how use and misuse of such metrics in evaluating performance is prone to backfiring).