Are there serious companies that don't use version-control and continuous integration? Why?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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.

Answer 14

At some point I worked on my own for three months. I had version control, and I had code reviews. Version control saved my arse once or twice when I found subtle bugs a bit later than I would have hoped and could do binary search to find where a bug was introduced. (Anyone saying “you would have found this earlier with unit tests”: No, I wouldn’t. Anyone processing dates here have a unit test for “3rd century BC”?)