What is the most effective/efficient way to develop an application with multiple people without source control?

Question

Introduction to my situation

I work for a small web development company. We have a team of four ASP.NET developers, including me. Almost all of our projects (> 98%) are one-person projects that take about 1-4 weeks to complete. We don't use source or version control. The only thing we have is a shared folder on a local server that contains the latest source (== the source of the live application) of all projects.

On the rare occasions that we do need to work on the same project with more than one person, we use... Beyond Compare. One or two times a day the developers ask each other if they have a version that compiles and then they synchronize their code using Beyond Compare. When only two people are working on a project, this works "rather well", but as soon as a third developers enters the process, it becomes an unmanageable piece of rubbish. Especially when everyone starts making changes to the database.

I (and one or two of my fellow developers) have already told my boss several times that we should start using some form of source and version control like Git, Mercurial or TFS (our boss is very Microsoft minded). Unfortunately, my boss doesn't see the advantage of switching to a source and version control system, because in his eyes everything works just fine now and he doesn't want to invest time and money in setting up a new system and making sure everyone knows how to use it. Even after I explained the advantages (like simplified collaboration, different versions of an application, safer way to change code, ...) to him, he still doesn't think it is something we need.

Of the four developers, only two (including me) have experience with source control (Git). And that experience is very limited. I know how to clone a Github repository to my computer, make some changes, commit them and push them back to Github. That's it.

Explanation of my problem/concern

In a few weeks we are going to start working on a rather big project for our standards. It will probably take 2-3 developers a few months to complete it. I will be the project lead (project manager and lead developer) and I will be responsible for everything. I've had my share of problems with our Beyond Compare approach and I don't want to take this road with this big project that will be my responsibility.

Since I doubt that we will be able to

• set up our own Git server,
• teach everyone to work with Git and
• employ Git successfully in this big project,

I am interested if any of you know some good ways to allow multiple people to collaborate on the same project without using source or version control.

Update

I would to thank everyone for their answers and comments. Here is the plan:

1. Have a meeting with the developers to make sure all the technical people feel the same way about implementing source control. We'll make a stronger point when everyone is behind it.
2. Present the idea to the boss and tell him that we really need source control.
3. Implement it as soon as possible.

Answer 1

Please take a day to install version control and teach everybody on the project to use it. It's not that hard. Personally I've not used Git, but I have set up and used other version control systems and they are not that hard to get working. Make sure you choose one that integrates with your development environment. This will make using it virtually seamless.

This will not be wasted time.

The time you will lose when someone overwrites or deletes some code will cost you much more.

If you don't have version control you will also spend an inordinate amount of time backing up your project and worrying about which version everyone has and which version is on the server etc.

If you need to convince your boss make an estimate of the time that it will take you to set up and monitor any non-version control solution and add in the cost of rewriting a few days lost work. Don't forget to add in the cost of manually merging edits from 3 developers working on the same source file and the extra cost of getting that merge wrong. Good version control gives you this for free

Then compare that to the cost of getting version control - nil (if you go open source) and setting it up - 3 man days.

Don't forget that an error later in the project is going to cost more than one early on. If you have to redo the entire project because of a mistake anyone can make this will cost far more than just the rewrite time, it might cost your boss the reputation of his firm.

Answer 2

If you share the source on a folder, you could share repo's there as well. The boss won't know about it except that there's a .git folder in there.

You should never have to ask permission to do your job properly - Seth Godin.

Answer 3

Setup source control, learn how to use it and don't tell your boss. I normally don't advocate disobeying management, but in this case your boss is being stupid. If you really think git will take too long to learn, then start with a more simplified version control system like svn - it doesn't do all the cool things that git does, but it's even easier to gain a basic understanding of.

Don't wait until you are into the middle of it and seriously in trouble before you implement something. Just do it, and get the job done.

Edited to add: What your question is really asking is 'how do I do source control without using a source control system'. You've recognized the need, and I think everyone here is really telling you the same thing: There's no sane way to do source control without a source control system.

Answer 4

I only have your summary to go by, but from that it looks like your boss is making a time and money argument, and you are making a technical superiority argument. You need to be making a time and money argument. Learn the git way of doing things and keep track for a while of the time it could save, then present a log to your boss with entries like "3/28/2011 had to wait 30 minutes for Joe to get back to a compilable build so we could do a merge, git merge command against his last commit would have been approximately 5 seconds" with a nice total at the bottom.

If training and setting up a server are business roadblocks, there are an infinite number of ways to set up a git workflow, including having only one team member actually using git, with shared folders for the "server."

Instruct your colleagues to copy their code to a given shared folder whenever it is at a good point to share. You can keep a repository for each of them and do all the source control stuff yourself, and slowly pass more and more of the source control responsibilities onto them as you become confident enough to train them. That's far from the ideal way to do it, but compared to what you have now, even that will save you time on merges. It's easier to convince your boss with less team learning curve, and you get all the rollback and versioning benefits you want.

I don't do much database work, but to my knowledge merging of database schema changes isn't handled very well by source control. If those merges are difficult, you may want to consider a process change where all database changes go through a single gatekeeper.

Answer 5

This is insane. You should use a VCS even if you work on your own. Not using a VCS in a company should be forbidden. Just do it. Right now! Really... You don't need advanced stuff right from the beginning. GitHub and GitLab are very straightforward to use, but I'm sure that you can find some more Windows-compatible hosting services if your boss insists (even though it's not hard to setup and use Git on Windows).

Answer 6

The think you ask is impossible. If multiple people are working on the same project without using any source control, you will quickly have lots of problems, and since you will be the lead developer, you will have to deal with them.

From my personal experience, working on a project without source control becomes impossible from two developers. Not three. Not four. Two. You may probably be able to manage the situation with two developers in some exceptional circumstances: if those developers are very organized and professional, if they interact well, if they can easily exchange (so are located in the same room at the same hours, every time) and if they are able to avoid human errors (modifying by mistake the file which was modified by another person at the same moment, then erasing the changes made by this person).

In my case, it was always more or less a disaster when it came to making two people participate to a project without version control. In best cases, one person was sending changed files to the second one, and this second one used a diff tool to apply the changes manually. In worst cases, one person tracked the changes she was doing, then reapplied them every time the second person modified the source code. Result: a huge loss of time, money and productivity.

Now, from my point of view and my own experience, I see three solutions to the issue you have:

• Install a version control which is easy to use. I used to install CollabNetSubversion as the SVN server, it's quite fast and easy to setup, if you don't care at all about security. If you use Visual Studio, AnkhSvn may be installed to enable the developers to update/commit the source code easily from within Visual Studio.

• Convince your boss that Joel test is written by a person who knows very well his job, and if Joel test suggests having a version control, there is a good reason behind it. After all, he can also decide that developers don't need an IDE/syntax highlighting tools to write code. Windows Notepad is just fine, isn't it? And also, why having internet access? All we need is a very, very old PC running Windows 3.1.

• Quit this company, since I have some doubts that everything except version control is perfect and professional there.

Answer 7

Not using a VCS on any larger project because you don't want to invest the time of setting one up is like taking a long journey barefoot, because you don't want to invest the time of putting shoes on.

Any VCS is orders of magnitude better than having none at all.

A dead easy way to set up a VCS is to get TortoiseSVN (since you seem to be using C#, I assume you're on Windows). You create a repository in a local folder you choose (navigate to it, right click > TortoiseSVN > Create Repository Here). Share this folder in your network (it should preferably be on a machine, that is always available) and make checkouts with the url file://computername/path/to/that/repository. Download excluded, this takes no longer than a minute to set up.

Answer 8

Your answer is a simple link to your boss... mail this page to him/her and highlight the number of times the words "quit" appear from professionals.

While the word "dumb" appears probably as many times, I am certain that your boss is not. It is just not clear to him the absolute value of this. The question to ask him is what business related question would result in the same response ( perhaps an accountant suggesting "Rather don't insure this building that you are bonded to the max it will save you a few dollars!" )

Answer 9

Source control is only necessary where the number of developers on a project is > 0. I'm starting to think that one might say the same about continuous integration...

(-:

As you're ASP.NET developers I'd suggest you want to go with one of Subversion, TFS or Mercurial - but to be honest it doesn't matter which just so long as you go with something. Developing without version control makes no sense whatsoever - even less so when the tools are more or less free to deploy and the overhead for using them is minimal.

TFS will give you a stunning level of integration. DVCS (mercurial or git) will probably give you the most flexibility and capability. There is no good reason NOT to do this.

If I were starting from scratch it would almost certainly be with Mercurial.

Once you have version control you can progress to a build server (TFS, TeamCity) and from there to continuous integration and at that point you start winning hand over fist.

To come back to your start point:

I will be the project lead (project manager and lead developer) and I will be responsible for everything

Right, you're responsible so you decide you need version control (because you do), you decide that you need an build server (because you do), you decide that you need to have deployable output from your project from the very first day (because if you can always deploy it - and hence facilitate more testing) and that the deployment will be highly automated - these are steps that you are taking to ensure the success of your project (for which you are responsible...)

Answer 10

As mentioned above, you can put a repository on the shared folder you already have. You don't need to spend time configuring a server if you use a distributed source control system, like Git, Mercurial or Bazaar.

I'd suggest you to use either Git, as you already have some experience with it, or Mercurial, which has good integration into Visual Studio.

If in the future your boss will tell you to switch to TFS, that is still better than to have no version control at all.

Answer 11

Back in my Powerbuilder days, we had a whole team working on a suite of applications without using source control. Oh, Powerbuilder had source control, but actually using it was a crapshoot - if PB crashed while you had a file checked out (and it crashed a LOT), that propriatary, binary sourcecode file was now inaccessible. Some flag got set in the file, and no other copy of PB could load it, even the same person who had it checked out.

So what we did was pretty simple. "Hey, Tom, I'm gonna work on xyz.pbl. So dont make any changes". In the grand scheme of things, we rarely had any problems.

Answer 12

Assuming you can't convince your team to adopt version control or that your boss gets wind of the subterfuge and insists that the team stop, there's a less-than-optimal approach you can take.

Install Git or Mercurial on your own machine. Version your own work. When the team syncs their work via the Beyond Compare process, add the changes to your local repo as a new commit. You will always be able to retrieve a previous working version from your local repo should the team's sync break something.

Using a DVCS ensures that there's no requirement to have a server and no complex setup process. Installing Mercurial and getting up and running with the basics should take no longer than about 30 minutes.

It's not an ideal solution, but it's better than nothing.

Answer 13

My initial reaction to this was that you already have an ideal working process without version control. You all seem to have a good way of managing merging and so on. From a managerial perspective, this is seemingly a good situation. I've met teams that use version control, but have to struggle with the development process itself.

So convincing your boss solely basing your argument on that version control would yield "a better process" is quite pointless. There is however another much more important argument on why you need to use version or source control in the first place, which can easily be calculated to money. And that is:

Risk

The issue is not that using source control makes your development process better. It is more of an issue what would happen if you don't have source control at all. What are the risks?

Say someone mistakenly deletes a function in code or a whole file? How much would that cost to repair? Hopefully someone has that covered, so the fix is marginal.

But what happens if no body had a backup of the lost file? How much man hours would that cost to fix? That would maybe take days, and that is easily calculated in average of man hours. Would that be too much for the company? Could this be remedied somehow quicker?

Yes, with some kind of source control. In contrast: how long time it would take to set up version control and back it up? Most open source ones such as git or mercurial don't take up much time to set up. Teaching people how to use it wouldn't be that hard, considering you already know how to merge with Beyond Compare and you "check in" to a shared folder. This is a one-time set up cost. Would these man hours be less than the ones that the risks have? If this is true then using source control should be a priority.

As long you can show a business reason why it is useful to have source control, and risk management would be one such huge factor, that would convince most bosses.

Answer 14

Use a Distributed Version Control System like git and use your shared folders machine to store the reference repository. Here's why:

Each clone is a backup

If the server hard drive crashes, everyone has a copy, ready to be deployed on a new drive or server. As your company is not serious about version control, I suppose it may be pretty much the same with backups.

Common reference

Having a main repository with a master branch allows to know the version that has the last word. This solves the "You have tested your changes against Franck's version, but did you have John's too? And how did you merge them?".

Deliver more comfortably

The customer wants an alpha version today? Well, you can test if master is stable enough and ship that. If it's not and you don't have the time to fix it, just go back in time and get an older but more stable version. You can't do that if you only have the latest version.

Go back in time and fix your mistakes

Your manual merge had issues that you only saw after after a few days, but you already have overwritten the content of your shared folders? Without a VSC you have no history so you can't easily go back to a point where you can check the mistakes you made and fix them. Code is not like a picture, it's like a movie: it evolves in time. You can extract a picture from a movie. You can't extract a movie from a picture.

Locate bugs more easily

A bug appeared but you didn't really noticed at the time it was introduced, so you couldn't fix it while the code was "hot". Now you don't really know which change introduced it, so it could come from several different locations in the code. It will take hours just to find where to look. With git, you could have just developped a test to say if the bug happens on a specific version, and use git bissect to find the exact commit that introduced the bug. Instead of looking for thousands of lines of code, you now know it's located in that 10 lines change, and you can keep the test in your test suite to make sure the bug is not introduced again.

Each developper is responsible for his/her own work

If you're the team leader, and have no VCS, you'll most probably have to do the dirty work, the merges. If you do it on your own, you probably don't know everything about all the changes and may introduce errors. On the opposite, if you always ask to the people that wrote the code to gather with you each time there's code to merge, then that's time they won't use to produce new code.

With a VCS, in a simple workflow, the developper only has to take care of his/her work, and one external source of changes: the master branch. There may be 1 or 100 people committing in the master branch, that's the same. To be able to push his/her changes, he/she will have to adapt them to the latest changes done by others. It may seem it takes longer to push code, but that's because you're also doing the merge which would have taken time anyway.

The difference is that merge is done by the person that did the changes, who knows that code best because he/she has written it.

Who wrote that code?

There's that bug here, but who has written that particular line of code? It's hard to remember, especially if the project lasts sevral months. git blame would have told you who and when that line was written, so you can ask the right person, and there's no "I don't remember writing that".

The project is getting bigger

The customer wants more features and you're a team too small, you'll need another developer. How do you manage the increased merge complexity without a VSC?

Urgent changes

The customer called and asked for a critical bug fix for the production, but you were currently working on a new feature. Just git stash to put your changes aside, or commit them in a new branch and push the changes and you're ready to start working on the urgent fix, without fear of losing your pending work.

It worked 10 minutes ago

You're doing some changes locally and something that worked 10 minutes ago stopped working. Without a VCS you either stare at the code or at best, do a copy of the reference version, and diff to see what you changes. Oh wait, the reference changed since I started working, so I can't diff anymore. And I didn't think to keep a pristine copy of the code I based my changes on.

With a VCS, you just do something like git diff right away, and have your changed compared to the right version of the code you're based on.

I have to keep my debug logs

So you're a bad guy and don't use logging? You had to sprinkle printfs in all your codebase until you found all those pieces of that nasty bug? Now you found one, fixed it, but want to keep your carefully crafted debugging code to fix remaining issues.

Without a VCS, you either need to copy the files, expurge the debugging code (which may add some editing errors), push that, and put back your backed up files. Oh, but it seems some debugging code got in anyway.

With git, you just git add --patch and select the few lines of code you want to put in your commit, and can commit only that. Then you resume your work and still have your debugging code. You didn't have to touch the code, so no copy/pasting error.

The big ball of mud

Without a VCS, people work on their side, and give you a bunch of changes, sometimes unrelated. When there's too much code to check, it's hard to find a bug.

A VCS will allow you to do small, incremental changes, and give you a changelog. The changelog is essential: people must tell there why they're doing the change, not what is the change (the what question is alredy answered by the code change itself). This means when you're inspecting some code of a new feature for example, you won't have to read lots of unrelated mixed changes like unrelated bugfixes. This helps focusing on the code you care.

If I give you 100 potatoes 1 by 1, and one is rotten, you will immediately find it. Now if I dump 100 potatoes in front of you and ask you to find the rotten one, that's not the same task.

Indentation

Hope you have good coding style policy, otherwise indentation changes will get you crazy if you merge by hand. Sure, you can ignore whitespace in the changes (but not in languages when indentation counts, like Python). But then you'll get weird-looking code hard to read.

You're the project leader

If you're the leader, this means you'll get the blame if things don't work. If you can't get comfortable with the situation because your boss still can't understand that using the right tool for the right job is worth it, then at the very least, I'd refuse to become the leader of a predictable failure.

Answer 15

Use dropbox, it has automatic version history. You can share dropbox-folder between multiple users.

Edit

You can also download TortoiseSVN-client, and create "local repository" on network drive. Then people can checkout the source code by network folder location.