I've taken jobs where they didn't have source control. A week later they did though.

If no one shows them how to do it and how useful it is, why should they change? Spread the word by pollinating other places with your experience and skills.

Agreed. Sometimes the most rewarding roles are ones where you have to start from nothing (or worse) and recreate a sensible working environment.

What's worse than nothing? How about legacy systems that are impossible to support and maintain? If you have reasonable management, who realise there's something wrong (they usually won't know exactly what it is), and are prepared to put their trust in you as a domain expert, you can often work wonders for them in this situation.

My last employer was like this. They had good people, but horrible practices that had become habit because of constant crunch-time.

During my interview I discovered that they did not use revision control. I agreed to take the job after they said they were going to start using a RCS.

Working there was a good experience for me as I was able to change a lot of their practices, and save the other developers future headaches. It felt good.

Other areas that were changed were increased use of reusable modules, extensive unit tests, increased awareness of security issues (especially sql injection), some WWW::Mechanize web testing automation, application monitoring, a group wiki knowledgebase, and an introduction to pair programming.

Since it is a perl shop I also encouraged them to take an active role at perlmonks, because my activity here has increased my perl knowledge tremendously. Providing the best answer you know to a problem can be very instructive, as it forces you to think through something that you "know", but might not know well enough to explain initially. And when others offer corrections or improvements to your answer you learn about the edge cases and internals.

Same here. I came onboard a recent project, and the code was splattered everywhere. Each person had their own way of making a backup, and that's when they took the time to do so. I saw files with .bak, .bak.bak, and every perversion of a date format used to create filenames such as my\ foo.bar.baz(qux).051006.bak.~~#123#.

I asked around. I figured maybe there was some kind of revision control system there. There was. RCS itself, the reverse-delta cousin of SCCS from the before time. However, it was out of date, and we really needed concurrant access and update to the files. After much searching for a formal procedure regarding it, I decided to implement SVN myself.

SVN is easy to use, and easy to host out of my own private account. A few extra scripts and a couple of cron jobs, and I had automated backups of the repository being archived away in a safe place. I even set up project member notification upon committing changes to the repository. It worked like a charm. No more guessing. No more difficult merges via copy/paste, or hacked diffs. And since it's not raw RCS, there were no locking issues preventing us from working on the source code.

When it came to deploying the new software, I simply checked it out of the repository as the production user, and poof! Easy updates. And even easier rollbacks, if needed. Deployment became simple and efficient.

The only advice I can give you is to always use a revision control system, regardless of the system. I have directly observed an improvement in the development process, project maintainability, and deployment consistency.

You will, too.

Contemplative,
-v.

"Perl. There is no substitute."

I was in your particular situation, personally, and know how much SVN has improved the situation there. In my current situation we had a problem just yesterday that SVN would have prevented. But, as several others have pointed out, since there were only two of us who were supposed to be working on the project, we thought that coordination would be sufficient to prevent problems. We have been proven wrong!

This morning we found a line of Perl was missing from a file. No idea how, who or when, but it's gone. Luckily, we do have good backups, but we are testing revisions, and it has held us up for several hours before we found the problem.

Guess what, I will be setting up SVN at my new site, and urge everyone to take similar precautions!

It depends on what you enjoy. I personally don't enjoy trying to fight inertia and incompetent co-workers. If you do, then my hat is off to you. But I've been through enough pain in the past to shy away from that.

If I was interviewing for a job, and It came up in the middle of the interview that they didn't use a centrally maintained source control system, I would walk out.

I wouldn't even be tactful about it, I would just say "I'm sorry, I refuse to work for incompetent people" and leave.