

Ask HN:  How would you convince your company to start using version control? - vital101

I recently started working at a fairly progressive marketing company with a small web development team (5 people).  Up until this point, they've managed the multitudes of sites that they have done by creating a "dev" folder on the web server, and then editing those files directly.  After everything looks great, they just do an rsync to the production folder and call it good.<p>Obviously there are a number of things wrong with this.  For instance, rolling back changes in the event of an error is difficult.  As someone who uses Subversion even on personal projects, this disturbs me greatly.<p>My question is:  How would you convince your company to start using version control software?  I'm not particular about the software, because at this point, something is probably better than nothing.  Also, the lead developer is the one who came up with the "dev" folder system and seems hesitant to talk about version control with me.  How would you go about dealing with him?
======
Kliment
Didn't Joel write an article about that sometime ago? Ah, here it is:
<http://www.joelonsoftware.com/articles/fog0000000332.html> The point of it
is, use it yourself. If you use subversion or whatever else (seems you are
familiar with subversion so go ahead and use that) then you can roll back
changes, you can do diffs, you have a full copy of the source with revisions,
and you can always tell rsync to ignore the .svn directories when you copy
things over to production. Eventually something will break, and you will be
the guy/girl with the magical powers to bring it back to a non-broken version
and find what has changed. Eventually, it will trickle to the rest of the team
that it's not a bad idea. Version control can be incrementally adopted. Just
sneakily do a commit after other people's changes, and show people how it
works. If not everyone adopts it, fine. There is certainly a strategy that's
necessary to make sure you don't step on each other's toes while editing
things. Use that to mediate between the source control crowd and the non-
source-control crowd. Forcing it on others is likely to be counterproductive.
Start using it yourself and let others see what happens.

------
mickt
I just wonder that if they're not savvy enough to use a RCS what other types
of battles will you have to fight in the future?

If I was in your shoes, I'd start looking for another job with a company with
a bit more technical sophistication. Somewhere that the battles you fight
aren't over trivial technology problems and practices and issues that already
have solutions.

Now that doesn't solve your problem, so probably the best thing is start using
an RCS yourself, then create a build system that will push changes out to the
server. You could initially sell this as a time-saver in updating the server.
Then start selling the whole history part of using an RCS to go back to
previous versions of a file.

But, if they're not using an RCS in the 21st century, what else are they doing
wrong, and should you really stay there? :)

~~~
jetsnoc
I am having this same problem with our development team (mostly c) at my job.
They find subversion too arduous but then don't understand why there are so
many problems and bugs in their releases.

Thank you for mimicking my sentiments precisely. I want to fight battles that
aren't over trivial technology problems that already have solutions!

------
pmjordan
Start using it yourself, maybe even with a cron job that regularly pulls the
latest changes into your local repositories. I give it 2 or 3 version conflict
or deleted file incidents where your use of VC saves the day.

~~~
vital101
I feel that there may be a chance of "Why would we need to user version
control when we can just use you instead?". I do like the idea though and will
probably set up a repository today for projects that I'm working on.

~~~
pmjordan
That would be you taking on more responsibility? Reason for a raise if you ask
me.

------
megamark16
When I started my last job they weren't using version control, so I just told
them that if nothing else it would be very easy and painless to just check in
every time we push to production so that we always have a snapshot of the last
version. The problem with them was that their developer would go and make
changes to files in production to fix bugs and issues, even after started
using version control, so it was always a chore keeping up with his hotshot
prod changes. You don't have to implement a full continuous integration
environment or start branching each developer separately, you can just start
catching snapshots along the way and it will have a positive impact on future
development.

~~~
btilly
The right solution to that is to overwrite his "hotshot prod changes" from
version control until he learns that he has to do it in version control first.

If you don't have enough political pull to make that stick, then you have a
second problem...

~~~
gte910h
Or you check in the production changes....

If you can't do this from your source control system, try something more
powerful.

~~~
btilly
That is a workaround but it has two major shortcomings. The first is that you
aren't getting the other developers to use source control. The second is that
you wind up with the challenge and the blame for breaking it in the case where
someone fixed it in production, someone else checked a different fix into
source control, and you are expected to merge them.

The simple rule, "You knew I was going to go from version control, your fault
for not fixing it in there" is a proven technique for getting people to
actually use version control. I've seen it done, and know people who did it at
several other organizations and it works. (Though at this point my first
impression of developers that don't know how to use version control is that
they must be incompetent people I'd prefer not to work with. Not using version
control a decade ago was somewhat more excusable than not know about it
today.)

~~~
gte910h
>"You knew I was going to go from version control, your fault for not fixing
it in there" is a proven technique for getting people to actually use version
control. I've seen it done, and know people who did it at several other
organizations and it works.

I know being an ass to people works. Tried and true for sure, very passive
aggressive technique to get developers to do things.

Also just keeping a production branch and development branch works too. Check
in the production changes to production branch.

Production hotshot doesn't port over changes or at least mention the important
ones to the guys working on the dev team? Kick that poor behavior to his boss
about how he's not pulling his weight, staffing problems are HIS problem not
yours, and by strongarming the guy with passive aggressive overwrites, you're
screwing the company AND the hotshot, rather than just the hotshot.

------
andrewcooke
one advantage you might use to "sell" the idea is that it lets people work on
laptops away from their desk more easily (i'm imagining that a marketing
company is full of people wandering round, brainstorming in cafes, etc... :o)

~~~
vital101
I hadn't considered the usefulness of this for the designers. Being able to go
pull up "that awesome design from last week" would probably be very attractive
to them.

------
gte910h
I'd say you should start using Git or Hg or any distributed system
immediately. No need to worry about getting complete adoption for those to be
exceedingly effective. Svn (or any "centralized only" SCM) is less capable in
an environment such as this as it requires everyone to adopt at once.

After you have a week or two worth of changes in your repor then you can
convert people one by one, and you don't even have to tell people about the
repositories you're using until it's time to try to convert them.

------
stonemetal
I would tell him you want to setup a source control server (That you
personally will administer so no overhead or extra work for him.) Have it be
fully optional aka people who use it have to fully comply with current
practices(Everyone has to be able to work as if it doesn't exist.) That way he
gets zero complaints from other staffers who resist change.

------
jarsj
Drop a note explaining potential disasters of using such a system to everyone
including your lead developer's boss. Then wait for the disaster to happen.
And then shout again pointing to your email.

------
p858snake
Perhaps put a business case forward with the benefits of transferring to a
version control system?

For example: * Easy rollbacks * Easily work on separate branches * etc

