A colleague of mine was under the impression that our software department was highly advanced, as we used both a build server with continuous integration, and version control software. This did not match my point of view, as I only know of one company I which made serious software and didn't have either. However, my experience is limited to only a handful of companies.

Does anyone know of any real company (larger than 3 programmers), which is in the software business and doesn't use these tools? If such a company exists, are there any good reason for them not doing so?

  • 3
    Those pesky software actors. Apr 7, 2011 at 12:31
  • 1
    are software actors different from software developers?
    – Aditya P
    Apr 7, 2011 at 13:06
  • "I'm not a software but I play one on TV!!" --Software actors. Apr 7, 2011 at 13:07
  • 1
    There is Jayne Seymour, she's a serious software actress.... or at least she played Solitare in Live and Let Die :)
    – Kevin D
    Apr 7, 2011 at 13:14
  • 3
    Where I worked ten years ago, we had nightly builds on all supported systems. They never got anywhere close to compiling. Ever. Apr 7, 2011 at 14:51

13 Answers 13


I'm not sure you'd call them a serious act, but MySpace are pretty poor on this front: See http://highscalability.com/blog/2011/3/25/did-the-microsoft-stack-kill-myspace.html.

  • 1
    +1 They are in the major league at least. I didn't think that was possible. Such a large company with no version control. Go figure.
    – daramarak
    Apr 7, 2011 at 12:40
  • Crazy. I wouldn't have believed it, but that blog and the references from the article are all reliable.
    – Steve
    Apr 7, 2011 at 12:46
  • Blame it on the dog.
    – JeffO
    Apr 7, 2011 at 14:39
  • 2
    A website for teenagers starting a band in a garage is written in the style of a coder working from their garage. Figures.
    – quant_dev
    Mar 24, 2012 at 23:32

You'd be surprised to see what reality can do to common sense ;-)

I think there are still quite a few companies out there not using a version control system. Interestingly in all the cases I've seen so far it's not because they willingly oppose the use of such systems but rather because they don't know that something like SVN exists! As for me: I totally agree with you and cannot image a situation where I don't want to use any kind of version control. Hell, I'm even pushing my own personal files (word documents, etc.) on my home PC into a GIT repository.

In the case of continuous integration system it's a little more common not to employ them in the day-to-day operations. Sometimes also because the people don't know such system exist but I've also seen cases where the - very questionable - excuse for not using them is that "we're not complex enough" or "it's working very fine without continuous integration, so why bother adding another technology?" Of course that doesn't stand a realistic evaluation - but to answer the original question: It's not all that uncommon.

  • 11
    Is it possible that a average software developer haven't heard about version control software? Where does these companies hire people from? The dark side of the moon?
    – daramarak
    Apr 7, 2011 at 13:05
  • 7
    @daramarak: Many (if not most) software developers don't read books, don't browse development blogs, and don't communicate with other developers (outside of their company) at all. If you get into development by teaching yourself with one of those "learn visual basic in 21 days" books, then you're unlikely to hear about version control. In fact, I don't recall learning about version control at university, only 10 years ago. Apr 7, 2011 at 13:53
  • @joeri - thankfully not true where I work, but I can believe it in general.
    – Steve
    Apr 7, 2011 at 17:53
  • @perdian - you say "quite a few companies" but don't give any specifics... do you have any links to articles, blogs etc naming and shaming? I'm not saying I don't believe you (in fact I do believe you), but data is always good...
    – Steve
    Apr 7, 2011 at 17:54
  • @Steve Haigh - No, I don't have any "hard" evidence. I've seen a few companies myself that don't use CI oder version control (whose names I'll keep to myself g) and with a little bit of extrapolation I assume that there are a lot more "out there". I think it's a lot easiert to find companies that do use CI, simply by looking at the reference list on the Jenkins page for example. But the other way around? There aren't a lot of people advertising "Hey, we don't use technology X" ;-) Apr 8, 2011 at 14:06

Just about every company in my industry (banking) currently uses version control. But it's certainly possible to develop software successfully without version control. 20-30 years ago. we did exactly that.

I would say many banks, maybe even the majority, don't use a build server with continuous integration. If you're already delivering software succcessfully without continuous integration, it's perfectly rational to continue down that road.

  • 3
    I don't agree that it's perfectly rational to "continue down that road". Yes, having delivered software during the last X years doesn't mean that it won't work the next Y years without any changes. However, after having introduced CI into existing (and quite mature) software products there is always something to gain from this. Apr 8, 2011 at 14:11
  • 1
    @perdian: there is always something to gain from lots of initiatives. So you have to balance CI against everything else. You can't just claim that CI gives you more benefit than everything else. You also have to measure opportunity costs.
    – HTTP 410
    May 18, 2011 at 15:15
  • 1
    @SK-logic: RCS was completely unknown at the time in the UK banking industry. And we developed some very large and robust systems without any source control.
    – HTTP 410
    May 18, 2011 at 15:21
  • 1
    -1 : "Just about every company" that's a too wide statement that is wrong. I've seen in the past year some companies that do not use any version control tool, relying on version copies on a shared directory. Yes, this made me cry. They said that "svn is too hard to use". OMG. But I still find some companies that are like that. Don't generalize, not everybody in the industry does know what is a source control system, nor does learn anything online, nor does know what a continuous integration is. (I agree that's hell. Happy to not be there anymore).
    – Klaim
    Jun 29, 2011 at 23:40
  • 1
    @SK-logic - ... what RoadWarrior stated, except in the marine/power industry here. I won't give names, but know at least two companies who are dominant in their sector (some specialized software development) for whom I believe never used VCS of any kind (in your sense). They had their ways of distinguishing good code from work in progress code.
    – Rook
    Jun 29, 2011 at 23:55

Just to put a counter point out to @RoadWarrior's answer:

I work for a Bank. I've spent the last 3 years getting version control implemented and have now managed to get it on around 20% of our codebase (which is quite large, we have approx 20 developers and have developed our systems for > 16 years)

Through my contacts in the industry (Banking), I know of a ton of other financial institutes that don't have what any sane person would call version control.

Yes, our industry (Software Development) is a lot sadder than most would like to admit.

  • My condolences. Sounds like at least some parts of the industry is seriously lacking the tools. I guess it's the story about the cobblers children again. Could I ask what an insane person would call version control?
    – daramarak
    Apr 7, 2011 at 12:51
  • 6
    Manually taking a copy of the code before you edit it. Eg, MyProg -> MyProd.old4 Apr 7, 2011 at 20:51
  • Sadly this practice is more common than people think
    – Craig T
    Jun 30, 2011 at 0:07

version control: In my first job 25 years ago there was no version control system as such, but this was RSX11 on PDP-11s. However, there was a very high level of quality control with formal reviews of design and code (this was in the nuclear industry).

Every job since then has used version control systems, including SCCS, PVCS, clearcase, cvs and perforce.

So in my experience the use of version control is pretty much universal in serious software development.

continuous integration: This is more of a problem, especially in places which have a lot of legacy code which probably doesn't even have much in the way of automated testing. It takes a very big investment to move existing code into a CI environment, and while it probably does pay off in the end, it's hard to get management to commit to such an investment for no short-term gain.

I've worked in one place (a large bank) which had CI in place for some projects, and we implemented a kind-of CI system on our project which did make things a lot easier, but took about 6 months to do.

  • For the places with legacy code, did they do automated builds, or did they have a manual building/deployment plan?
    – daramarak
    Apr 8, 2011 at 7:38

I would imagine that MOST companies don't use these things, because they don't understand the benefits and their developers either don't want to learn or are afraid to "stir the pot" by doing things different to how they've been done before.

  • 3
    Absolutely! I've heard the answer (or maybe we should call it lame excuse) "we haven't used it so far and since it worked (somehow) we don't need it". It's a shame how resilent people are against changing their tools. Apr 10, 2011 at 17:05
  • 1
    I cannot stand people like that; sadly that's the type of "developer" I've encountered all too frequently in my career, and I just can't deal with their ignorance and always look to leave a company where those types of developers are prevalent. At the risk of sounding downright hostile, those kind of people are a cancer upon this profession. Jun 30, 2011 at 13:07

Although I'm an employee now, I used to be self-employed as a database consultant. During those many, many years, I was in somewhere between 800 and 1000 companies, from mom-and-pop level to Fortune 100s.

I saw relatively few places that did continuous integration, but I don't recall ever seeing a company that didn't use version control. I did see a few where there was no centralized repository for version-controlled code. Individual programmers used version control either on their own computers or kept version-controlled code somewhere beneath their home directory on the server.

I don't think any of these companies was in the software business, but their programmers certainly were.


A colleague of mine was under the impression that our software department was highly advanced as we used both a build server with continuous integration, and a version control software.

Nope I hate to say it, but this is true. The last two places I worked (a division of a bank, and a finance company), I was the one who implemented the version control system. A number of places (especially non-software shops) don't understand why it's really necessary for long term development. The team normally starts out as one or two people and then grows from there, albeit painfully. With one person or two people you can get by (not well) without it because you can be in almost constant communication with each other.

Continuous build is an entirely different case. If I had to guess I would bet that almost 90% of the places where development is done doesn't have a CI solution in place. I go to conferences and most people are amazed that an organization other than an MS or Google has it. What I have found is that management doesn't want to spend the small sum of money to get it up and running even though it can save a lot of time.

The biggest reasons I've found for this are:

  1. The people in management have risen through the ranks at the same organization. They never used and didn't need it, why would they need to change now? Some I've found are just afraid of change. Something new is scary, and it would prevent them from dusting off their old compiler and help our the younger ones in time of need. Other times (and more often), they have budgets which are always tight, and they have to make decisions about where to spend money. For us implementing these is an obvious need, but that's because we've used them before. We know the benefits, they don't.

  2. Managers are non-IT people, and all they here is that you want to spend money on something that hasn't been needed before.

Most arguments I've heard from people center around best practices etc. and those are true, but what most devs don't understand is that you have to frame it in terms of a financial situation when in this scenario. With this amount of money you are going to spend, we are going to save X amount of time, and you need numbers to back it up. This isn't always true, but has been my experience in the past.

  • I can imagine that problems like this arise when there are poor communication from the developer and upwards in the managements. Thankfully not all companies are like this. Where I work, we are expected (if not obligated) to tell the management if something could make us more effective.
    – daramarak
    Apr 8, 2011 at 7:41

I would say many people don't use source control because they may be coding on their own and are used to backing up the codebase to a central server or USB hard drive periodically. I forced myself about a year ago to start using SVN because I knew it would be beneficial in the long run. It took a while to get used to it but now I have tons of code history that I can constantly reference. I wish now that I had implemented it four years ago when I started.

Continuous integration? Only use it if you need it. For me, there are just two software engineers so we would not benefit from continuous integration because we working on our own software by ourselves.

  • 1
    Continuous integration is supposed to identify errors when they occur. Even two developers need that.
    – daramarak
    Apr 7, 2011 at 13:10
  • 1
    @daramarak: Not if the two engineers are working independently on two separate products that are not integrated. Apr 7, 2011 at 13:45
  • 1
    CI is one of those things that I'm willing to do without. Personally I'd love to have it at my job, but it's not going to happen anytime soon. We do have automatic builds 1-2 times a day though, and that really is sufficient for our needs.
    – Michael K
    Apr 7, 2011 at 14:26
  • 1
    With an automated build you are halfway there. Just knowing that everything checked in compiles can be a joy sometimes ( "It compiles on my machine" )
    – daramarak
    Apr 8, 2011 at 7:36

Ha, you think you're advanced because you have SCM and a CI system? Let me tell you that's amateur hour when it comes down to it.

A lot of companies do the minimum required, because that's all it really needs. If it works, and you get good reproducible releases without major effort, then there's nothing that needs to be fixed. The last thing you want to do in such circumstances is start to 'fix' things, especially when it comes to taking admin resources away from their work to set up and administer your new servers and build systems.

However, some companies require a bit more stringent systems in place, once that not only do the build, but control the requirements all the way through to the deployment via test plans and test results, taking in code review, workflow-style checkin procedures and team-leader designated work package management. That's real configuration management, and be damn glad you don't have to work in that kind of environment!

I've worked at a few companies, and I can't think of any that didn't have some form of SCM. Some of them were more comprehensive than others, but all of them had a system that worked well for them, even the ones that used VSS.

  • lol ! signed : a professional.
    – deadalnix
    Jun 29, 2011 at 23:43
  • I agree, SCM and a bug tracker is the development equivalent of wearing pants to work. CI is basic automation of a critical function. Like automatic backups but for releases. Ah, CCB meetings. Every week, like clockwork. Jun 30, 2011 at 0:23

Even with two programmers when your working on complex applications and a list of tasks it can be difficult to not hammer each other's changes.

Even our old release management software showed the changes side by side and allowed them to be applied in either direction. Changes would have been missed on more than one occasion without it.

I see a number of benefits that come from CI but I can't imagine why any company wouldn't make use of version control software.


The last job I worked at without version control was in 2006 (I'm a Web developer, FWIW). The company only had about 2 or 3 developers before hiring me, but I was the first of 10 or so developers hired in just a couple of months. One of the first things I did when hired was introduce version control (CVS, because I didn't know at the time how badly it sucked!), but many of the developers hired after me couldn't get it to work on their dev environments, so didn't use it. Oh, did I mention that they didn't even have local instances of the application running? They hacked code on the server. And no automated tests, of course. I cringe when I think back on it.

Before that, I did some AS/400 programming work without version control. I don't know if a decent VCS was even available for that environment.

Now I use Git for all my one-man projects, and my last several jobs have used it too.

CI is a different matter. It's great to have, and I encourage it, but it's less essential than version control, at least for smaller projects in interpreted languages. Most of my recent jobs have had CI servers, though; among other things, it means that no one can forget to run the full test suite before deploying.

  • 'CI is a different matter. It's great to have, and I encourage it, but it's less essential than version control, at least for smaller projects in interpreted languages.' Agreed. CI is really only necessary when you are doing frequent and/or complex builds and it starts taking up a lot of your time, or you want to run a test suite, or you want to be able to stage multiple branches, etc. If it's a PHP project with have a dozen developers, no test suite, and you push to production once a week, you'll probably want to focus on a good QA workflow before you start worrying about CI. Aug 5, 2015 at 0:53
  • And you'll probably want to focus on a good test suite before you start worrying about QA, or anything else. Aug 20, 2015 at 23:04
  • Maybe in theory, but if you're using open source software, unless it ships with a test suite, this is practically impossible. I have not once worked on a PHP project that had proper, full test coverage, but every project I've worked on has had some level of QA. Aug 21, 2015 at 2:53
  • @siliconrockstar I was talking about having a good test suite for your own code; appropriate level of testing for library code is quite another matter. Aug 28, 2015 at 13:20
  • @siliconrockstar For what it's worth, most Rails projects I've worked on have had excellent developer test coverage (the exceptions were actively trying to improve it); not all have had formal QA. It's much less necessary to have formal QA with good tests, though it's still a very good idea. However, development without tests in place is incredibly risky, so that's why I say that improving tests should be prioritized over anything else. Aug 28, 2015 at 13:22

I've definitely run into a few here and there, but mostly small companies. The problem I see more frequently is companies that actually have SCM, but deem many projects too small or unimportant to track in them.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.