I've had 3 years of prior development experience with two different companies. One used SVN. One used VSS (Visual Source Safe. Not the greatest... but it's something.)

In my last web development role, during the interview process, I asked about the version control they're using and they said "We tried SVN, and we tried GIT, but right now we're just passing zip files around".

I thought that was a bit weird, but I took the job anyways. I... was not impressed.

I'm now job seeking again, and I encountered another company that is currently not using any version control.

Under what condition is this an acceptable answer? How should I proceed with the company if I am still interested?

  • However they're doing things is acceptable if you're okay with it. Nov 13 '17 at 6:04
  • 1
    The problem is I have no idea how they are doing things at the interview level. I myself can't think of a reason why they wouldn't use version control, because I use it even for solo projects! Even something like sticking it in Dropbox is version control...
    – Nelson
    Nov 13 '17 at 6:23
  • So ask them to explain to you how they make things work that you'd use source control for? Nov 13 '17 at 6:31
  • It's a rather large red flag. It's not completely uncommon (I've worked with companies using their ERP tools for managing tags/releases only), but it's an indicator that the company does not value software development.
    – pmf
    Nov 13 '17 at 7:05
  • 3
    I think this belongs more to Software Engineering SE than here (but I can't flag it to move there for some reason). As far as interviewing go, you already know that you would prefer company that uses source control. You either make it deal-breaker, or you try to assign some value so you are able to decide whether to take a job or not. I don't think we can help you in deciding how valuable source control is for you... Nov 13 '17 at 7:59

I don't think I agree with the other "it depends" kind of answers. Not using any kind of version control is a huge red flag.

The fact that they are not using a known solution would not be a problem in my point of view, but they are stating they are not using any kind of version control, let it be internal or external.

It probably means you will pass hours and hours solving client bugs, trying to manually merge already corrected bugs in god knows how many files from release bundles. Have you asked about release versioning, by the way?

I would not consider the position challenging, because if they are still a company, I don't see how building complex and reliable software is possible by having a human doing the log database, merging modifications in multiple files, manually tagging releases.

Bottom line is: issues with client support, bad software reliability, not a challenging position.

  • 6
    No version control (be it Git, SVN or a bespoke/internal one) has to be a deal breaker. Such a company likely has other awful processes.
    – async
    Nov 13 '17 at 9:38
  • 8
    In my experience companies without version control have a "its no big deal, we'll use the temporary fix as a definite solution to our problem" attitude about everything. Even it is possible to work that way, a lot of important issues will rise up, and generally this kind of company won't even try to solve them, just work around them. You end up spending most of your time working around everything and not actually getting your work done.
    – everyone
    Nov 13 '17 at 9:53
  • I managed to implement version control on the few companies that I worked for without it. It's not because they don't have it currently that they can't start using it with the proper incentive!
    – T. Sar
    Nov 13 '17 at 10:45
  • Oh, working on such a project would be challenging for sure, except that the word challenging in that context would mean something different from what we normally use it for.
    – Masked Man
    Nov 13 '17 at 12:47
  • I would add in the list of the reason of the red flags thing : it is possible that they don't use it because you will be the sole developper, and lot of us prefer to works in teams.
    – Walfrat
    Nov 14 '17 at 11:42


It's all about the value judgements. There must be some factor which attracted you to this job in the first place: maybe it's close to your home; maybe you like their product; maybe you "click" well with the team. You must weigh these good factors with this screamingly negative factor of no source control.

Personally, I'd treat lack of source control as a gigantic red flag which likely betokens a lot of other process problems which you won't enjoy. I'd likely not join them at all unless I'm hired with the mandate of helping to rationalize this situation.

Your mileage, of course, may differ. As above, take this datum as just one of the factors which weigh into the overall decision you have to make about the company.

Good luck!


There are no conditions for a company to not be using source control except one. That's when they are trying to hire someone to implement source control. So if you're interviewing for the position to implement source control, ok, go for it. If not, you can do better.


The first thing you should do after hearing this, is to inquire further, and find out why on earth not.

In the end, not using source control is simply one point of data about the company. It doesn't absolutely establish anything. It does give you a pretty strong prior that the developers at that company are not very experienced, or not very disciplined, or that there is something very idiosyncratic about their development process, any one of which is strong grounds for concern. Depending on the situation, it could be a flashing red light, or there could be other factors that outweigh it. For example they could have an absolutely genius business plan, but you are the first experienced developer they've hired.

  • Agreed. Even without source control, I mean, passing zip files around? Even using shared network files and (slightly better) copying them locally would be easier (though still terrible). Do they not know even that? Nov 13 '17 at 10:39

There are some industry specific software development environments which preclude the use of a programmatic version control system (like git or svn).

In those cases I would (as a prospective employee) expect the company to have a manual software release versioning process so as to control the versions of their software.

There is a big difference between no version control and not using a solution like svn or git.

For example, in the software development space of the insurance industry the largest financial modelling software packages require coding for them to model the business of a given entity, but do not lend themselves at all to an SVN like system.

Audit requirements, however, generally mandate the implementation of a more manual version control system for these models.

  • I have worked for an insurance company (albeit for a short period) and this does not ring a bell. But I could see how VBA scripts inside an Excel sheet are not easily put under source control. Still a red flag - such VBA scripts are known to be problematic from a software maintenance perspective.
    – MSalters
    Nov 13 '17 at 10:32
  • @MSalters the software I’m referencing (actuarial modelling software pacakages) have similar problems to version controlling an excel/vba spreadshet, as they are simultaneously a development environment and a production model run environment. Yet it is required that a software package like this is used to value the insurance business that a company has sold. (The base software provides features [like distributed processing] which should not be developed in house in an insurance company)
    – illustro
    Nov 13 '17 at 10:46

It's purely up to the company if they want to use version control or not. If it's something you can't live without then decline the job.

If their network is built properly version control in terms of git etc,. isn't needed. I use neither but have an engineering solution instead.

  • 1
    Hmm ... I'm reminded of VMS file system which I used long ago. Though I long to open a huge discussion of auto-backups vs formal version control, I'll be a good citizen and just thank you for the info. ;D
    – akaioi
    Nov 13 '17 at 6:41
  • 18
    Good backups are not a replacement for version control and version control is not a replacement for good backups. They serve different purposes.
    – Brandin
    Nov 13 '17 at 8:26
  • 3
    @Kilisi But can you retrospectively check why the change was made? Or you know that regression happened so you want to short-list changes based on what they are doing? If anything else the VCS provide a standard tools to do such things. Nov 13 '17 at 8:44
  • 2
    Such a poor answer. OP wants to expand his knowledge and understanding of practices across the industry, and you answer with "if you don't like it, move on".
    – async
    Nov 13 '17 at 9:32
  • 1
    This is awful advice. Version control is very important, even for a company only producing a small amount of software. How else would you track when you made a change, or do something like create new branches and later merge them? I wouldn't go near anyplace that told me to use backups as version control. Nov 13 '17 at 12:13

Not the answer you're looking for? Browse other questions tagged .