
Ask HN: Why should my company use source control? - SamuelAdams
Hi guys,<p>I&#x27;m a programmer at a big company. Prior to working here, I have worked at several other organizations who all used Git as a version control system. As a result, I am very well versed in how to use git.<p>However, my department does not use version control at all. They simply do not see a need for it. So far, most of my reasons for using source control have been discarded due to another tool already doing that thing. For example:<p>* Git is a backup of your source code. If your code is on the server, and you lose your laptop, you&#x27;re still relatively OK.<p>* Rebuttal: We store code on a network share, which is backed up automatically every night.<p>* Git allows people to easily collaborate on the same project (branches, pull requests, merges).<p>* Rebuttal: We rarely have multiple people working on the same system at the same time - the benefits will be negligible, and only add complexity to our daily work (this is true, work here is very silo&#x27;d).<p>* Git allows you to store a version history so you can see what changed and why.<p>* Rebuttal: We don&#x27;t care for the past: we only care about the current state and what it&#x27;s not doing correctly (or needs to do &#x2F; enhancement).<p>So, HN, my question to you is: what other benefits of Git &#x2F; source control exist that I can bring to management to hopefully swing our team into using it daily?
======
sethammons
Reading the post title, I think my brain hit a segfault.

I sometimes want to undo an hour of work. Git to the rescue.

I sometimes want to compare code now to code then. Git the the rescue.

Sometimes, I have to undo days of work. Git to the rescue.

Sometimes a really good git commit will help me understand why something
changed (though, I contend this should be documented in the code with
comments). Links to tickets, other files that were changed at the same time,
etc. Git to the rescue.

I _want_ code reviews. It is how we learn from each other and get better. Git
to the rescue.

I run automated tests against my code to make sure it works the way I want.
Multiple layers. Especially at the black box layer (ie, does it do what the
customer wants). Sometimes my new code breaks tests and I want to easily
switch between the known stable version and my broken version as I fix my
version. Git to the rescue.

Sometimes I want to share my code to help a colleague learn. Online source
code viewer to the rescue! (cough, Github, cough). To leverage Github? Git to
the rescue.

------
carapace
Just get another job. Life is short and ain't nobody got time for this in
2020.

~~~
zapstar
Yes, if you're in the position to find a job elsewhere, do it. This is an
uphill battle that you don't need to fight. And there's no guarantee that you
would win -- reason is of no use here. The most perfectly-constructed rebuttal
will not be effective.

------
Scarblac
Daily backups help nothing if you accidentally delete a file you wrote today.
It's far too slow.

Being able to review code by a coworker before it is merged into master is
also a big one, as well as having different versions around for currently in
use, currently being tested, currently being developed and so on.

But they sound like they have already made up their mind, and you will build
negative work experience in your time there...

Anyway you can still use Git locally I guess.

------
probinso
First let me say HAAAHAHAHAHAHAHA

Now that I have that out of the way...

don't sell them on version control, they obviously don't care. Sell them on
oversite in project management tools that are coupled with the code versioning
system. Then bate n' switch them.

------
davidw
Yikes. The snarky answer: find a better place to work.

I mean... people have been using version control for decades. It's not
controversial.

~~~
SamuelAdams
Well tbh this is a really great place to work at and I really enjoy it. I just
want to make some progress on the tech tools front. There's a lot of other
really good things going on at this org, so I don't think this will be a hill
I'm willing to die on.

~~~
DEADBEEFC0FFEE
Instead of preaching source control, why not try framing the problem you
perceive as risks that others can empathize with. If you can't, then perhaps
it's not truely needed in that workplace.

~~~
carapace
Where are you coming from here? You're all over this thread hating on DVCS.
Did version control kill your dad or something?

Why _wouldn 't_ you use version control?

~~~
jbn
yes why would one _not_ use version control??, sounds like dogma to me (a bit
little being anti-vaccine IMHO..).

------
tboyd47
Imagine if instead of having to go ask the author why they made a certain
change to the code, or look it up in documentation, every developer on the
team already knows the reason behind every change made to the system, and this
is true going forward even if the entire team is replaced.

~~~
DEADBEEFC0FFEE
GIT does not make good commit comments. That's a practice that can happen
without git.

~~~
tboyd47
The author's co-workers are objecting to using any version control at all.
Here I am thinking, they must be database admins ;).

------
ericlewis
I would push on the version history, having a history lets you understand
decisions and codepaths that lead to it not working correctly. This is
invaluable, and if anything breaks majorly: you can roll back.

------
robcohen
Yikes. I have had the misfortune of working in places where explaining the
benefits of basic technologies lands on deaf ears. This happens a lot with
regard to infosec (requiring 2FA, enforcing password manager use).

Quite honestly just do your best to move the company forward. There's really
very little reason to not use best practice approaches, especially when doing
so costs nothing other trekking the learning curve.

If you get too much resistance, find a better place to work.

If you are a dev, you don't want to be working anywhere that is failing to
follow the most basic best practices.

~~~
DEADBEEFC0FFEE
You didn't offer a single compelling reason to use source control.

------
frou_dh
> Git allows people to easily collaborate on the same project

> Rebuttal: We rarely have multiple people working on the same system at the
> same time - the benefits will be negligible, and only add complexity to our
> daily work (this is true, work here is very silo'd).

Working for long stretches in this kind of culture is likely to stunt your
personal growth. You can learn more in 6 months of direct collaboration with
someone who really cares about development, than in 5 years at a silo'd place
with little to no collaboration.

------
Jtsummers
Their last rebuttal is the problem. You could easily counter the others.

First rebuttal:

> We store code on a network share, which is backed up automatically every
> night.

Git (and other version control systems) permit more frequent backups
independent of policies established by the sysadmins.

Second rebuttal:

> We rarely have multiple people working on the same system at the same time -
> the benefits will be negligible, and only add complexity to our daily work
> (this is true, work here is very silo'd).

If most things are only touched by one person, then git (and most other
version control systems) add negligible complexity. While not advisable, you
could even have them work off of master (as they do now anyways). [This lets
git be a gateway to process improvement. Once they see the fine-grained
snapshots and realize they _could_ have people work on the same code at the
same time, they may start using branches and other capabilities.]

That last one, though, indicates they don't actually care about anything. The
past is not gone. Having these snapshots lets you do a _lot_ of useful things
like _git bisect_. Or the ability to easily rollback to a known good state. If
they really don't care about that, I'd run, not walk, to the nearest exit.

------
downerending
Note that even if the _company_ doesn't use version control, you probably can
do so _yourself_ (e.g., with a personal git repo) and get a lot of personal
benefits. I've done this at a few shitty jobs.

Believe it or not, it's better for you that there is no version control than
that they force a bad one. (Looking at you, Perforce.)

------
0x1221
What do your colleagues think? Or is every engineer in this big company also
incompetent in addition to your management?

~~~
SamuelAdams
Actually management has been supportive about using newer technologies. We
have a BitBucket server and it's updated regularly.

The general consensus from colleagues is that it's complex and is overkill for
the type of development this department does. Many of the benefits I cite are
already being met by other systems, so they don't see why they should bother
switching to it.

------
giancarlostoro
If there was flooding and all the hard drives failed would you lose all the
code? I've heard multiple times about game studios suffering a flooding and
losing lots of code.

Version control has lots of uses, it helps you branch out and test new ideas,
it saves your code from local doomsday scenarios at the office. Helps you to
ask the correct developer what the code is supposed to do due to version
commit history.

You can always keep your own local git repo. A coworker had a git repo inside
an SVN repo, just add each version controls contents to a git / svn ignore
file.

~~~
DEADBEEFC0FFEE
Offsite backups should be in place for this scenario. It's also extremely
rare, and any place not aware of this threat is probably failing in other
areas.

------
Wowfunhappy
...I honestly kind of agree with your department regarding points 1 and 2. If
programmers never collaborate, and they have a backup system in place, then
you don't need git for those things.

But point 3 is a super big one, so I'd focus on that. Is there _really_ know
time when your company took something out that they realized they wanted
later? There's never been a regression they had to roll back? Really?

If not, you might tell them that it's helpful to you as a programmer to be
able to refer to how something was done previously.

~~~
austincheney
I disagree in that it sounds like the OP's organization is staffing to the
limitations of their technology. It reminds me of working in subversion where
people would never collaborate for fear of commit collisions. This super bad
from a knowledge perspective in that people don't cross train and instead
become reclusive experts that they use to justify their existence and
continued value.

For me, personally, the biggest win of git is ease of branching allowing for
rapid and easily disposable experimentation in the source code.

------
throw51319
This is a ridiculous question. If your current state doesn't work, then of
course you want to go back to the last state available that works. Git gives
you more control over this.

~~~
SamuelAdams
Right so (I think this is silly but this is how colleauges have been doing it
for years) if a change to a production system is required, first people back
up whatever artifacts are being changed to a folder on their computer or a
network share. Think like stored procedures, report definitions, SSIS jobs,
whatever the thing is. That all goes in a BACKUP folder, then you make your
change, test it, then put it in prod. Then you hang on to that backup folder
for 1 day to a month, depending on how often you clean house.

I think this is silly, of course. But the reality is this org doesn't have
very many changes to production that go wrong, so maintaining a version
history seems like added overhead to every change.

~~~
throw51319
It's not even a lot of overhead though. They just make a feature branch, have
that PR'd back into the master on github. That's it. Like 3 mins of work every
medium feature.

------
jwalgenbach
If you have a breaking change in a new version of the code with lots of
changes, or don't discover the break until several revisions later, git can
help find the responsible code with git bisect.

The idea is to manage and track change to your code base so that you can
answer questions about the code base efficiently when there are problems.

------
codegeek
Tell them that you overwrote several hundred lines of code by mistake and now
there is no way to get to the previous version. Do they have a backup for that
previous instance ? If not, they have the answer.

~~~
bdcravens
If there is a piece of code that is uncovered by a backup, it's likely pretty
new. For git to help you, you'd need to have committed that code at least
once.

~~~
Scarblac
Yes, of course. But it's normal to commit many times per day, it takes hardly
any time.

------
borplk
If you are otherwise happy with the job I'd say just let it go. You don't need
to fight anyone or convince them.

------
kazinator
> _we only care about the current state and what it 's not doing correctly_

That's just too ignorant for words.

You're trying to teach bush people to boil water to kill germs.

------
taway555
what about code review? And if the answer is that everyone at the company is a
rock star and doesn't ever need code review, then I'll be at a loss of words.

~~~
SamuelAdams
Actually this is a great point and something we want to improve on. Code
review / pull requests would be a great talking point. I'll be sure to bring
it up.

~~~
taway555
Every single line of code at my company is subject to a peer reviewed pull
request and isn't accepted unless at least 3 people approve it.

~~~
seattle_spring
That seems wrong, but on the totally opposite end of the spectrum. 3 people
seems like huge overkill.

------
Foober223
You can use git locally to get some of the benefits for yourself. No one even
has to know. Distributed git FTW.

------
dyingkneepad
[https://git-scm.com/docs/git-bisect](https://git-scm.com/docs/git-bisect)

------
saluki
y, it's tough changing 'the way we've always done it'

I would just use git/github locally for what you work on, then you can enjoy
the benefits.

Perhaps at some point they will need to see what something looked like 6
months ago and you can WOW them with the magic of GIT.

Good luck, it's tough trying to change culture.

------
factorialboy
Which industry is this? Make a security / compliance case that mid-management
cannot overlook.

~~~
SamuelAdams
Education.

That's what I was hoping to build here - a list of reasons why git is a better
tool we should take advantage of. However, the business reason for many of
git's benefits are already being met. For example, all source code must be
backed up. That's already being done, just not through git.

Are there other security / compliance requirements that I should consider?

------
Sevii
How do you safely rollback changes?

~~~
SamuelAdams
Make a copy of system artifacts and store it in a folder called backup on a
network share. If things do go wrong just copy the backup folder artifacts to
production. May need to also write some data cleanup scripts if data was
altered or columns added and so forth.

~~~
DEADBEEFC0FFEE
Is there a possibility you just like GIT because you have skills in it?
Totally ok to be that way, you're probably productive with it, but are you
sure there won't be a non trivial learning curve for others?

~~~
tcbasche
to be fair, if you don't know any version control, and aren't willing to learn
it (in 2020 of all things!) then why the ever-living christ should anyone put
up with that?

------
techslave
branches. code review. obvi you can do both without SCM but boy does it help

------
stakkur
Here's an (extremely) short but useful explanation of 'why':
[https://docs.microsoft.com/en-
us/azure/devops/learn/git/what...](https://docs.microsoft.com/en-
us/azure/devops/learn/git/what-is-version-control)

TL;DR: source control is about so much more than 'backing up'.

