HN Explorer

Ask HN: Why should my company use source control?

18 points by SamuelAdams ↗ HN
Hi guys,

I'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.

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:

* Git is a backup of your source code. If your code is on the server, and you lose your laptop, you're still relatively OK.

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

* Git allows people to easily collaborate on the same project (branches, pull requests, merges).

* 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).

* Git allows you to store a version history so you can see what changed and why.

* Rebuttal: We don't care for the past: we only care about the current state and what it's not doing correctly (or needs to do / enhancement).

So, HN, my question to you is: what other benefits of Git / source control exist that I can bring to management to hopefully swing our team into using it daily?

63 comments

[ 3.0 ms ] story [ 115 ms ] thread
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..).
Gibbon1
Yeah pick your battles. Nothing really stops you from using git locally.
twunde
While people have been using version control for decades it only became the norm for all projects since github became popular. 2010-13ish I would regularly meet senior/mid-level engineers that weren't familiar with Git. In companies that are not tech-first, it can be a battle to get developer tooling in place since its not a feature. Anecdotally, I worked at one place where the deploys were manual FTP file by file for a team of 12-15ish engineers. Automating deployments basically gave us back 1-2 engineers.
davidw
People have been using version control since I started coding professionally in the 90ies. Granted, it was much crappier (cvs and then subversion), but it still was much better than nothing at all.
DEADBEEFC0FFEE
I have worked at places where they just create a new folder and copy everything over. Backups do the rest. Occasionally they would ask for a restore and do a diff.
jbn
backup aren't usually reliable (and if they're not tested, they are absolutely not "reliable", you just don't know...), and that's a horrible way to get back old artifacts (it surely is excruciatingly painful compared to just using source control). I think anybody sane would just refuse to work at a company with such practices..
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.
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?

DEADBEEFC0FFEE
Why make it a security case, if it's not. If the IP is protected and available without GIt, why make stuff up.
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.

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.
SamuelAdams
That's a good point, me being new, I have already encountered a few projects where no one is really sure of why things are the way they are, but they work. I'll add this to the list.
tboyd47
Yep. To be fair, you really need to combine it with a good ticketing system to get that effect.
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 ;).
detaro
How do you make commit messages without any form of source control?
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.
[deleted]
(comment deleted)
seattle_spring
That seems wrong, but on the totally opposite end of the spectrum. 3 people seems like huge overkill.
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?
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.
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.
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.
carapace
Just get another job. Life is short and ain't nobody got time for this in 2020.
aprdm
lol I laughed pretty hard but it is actually a good advice.

Otherwise I guess you can just use git in the NFS by doing git init and local git workflows... I can't do anything without git, even throw away code I start with git init.

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.
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.
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.

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.

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.

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.

[deleted]
(comment deleted)
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.

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.

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.

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.

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.

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.)