At my last company I was really the first and for a while only coder there. At previous jobs they had always used one of the two popular version control systems: git or subversion. These are fantastic for backing up source code, reverting to previous versions, and sharing code across workstations. These days it's almost a given that if you're going to be coding full-time you're going to use (at least) one of these two platforms- almost. This was previously a company of all designers, and most of them did their work in adobe programs like InDesign, Illustrator, and Photoshop. They faced the same risks of losing their files, and the solution commonly used was a combination of a shared cloud drive and each computer station backed up by Time Machine, which is a mac os program described as a, "built-in backup feature of OS X". It is sometimes called a "ghost drive" because you have an external hard drive that continuously copies and stays in sync with your main hard drive. This is a mac-only program, but I'm sure you can do a similar "ghost drive" technique on Windows or linux. After using this system for a while I began to like it a lot and started to wonder if this could be a viable option for more code-focused development companies.
Eliminating Source Code Loss Risk
In my opinion, the most important reason to use a version control system is to prevent against the possibility of a unlucky event wiping out your entire codebase. For example, if all of your code is saved on your computer's hard drive and you, say, drop your computer in the ocean or your hard drive just out-of-nowhere dies on you, you're basically screwed. That's why you need to save to something outside of your computer's own disk. Git and svn solve this is a fine way, but the Time Machine ghost drive does this as well and with much less work from the developer.
Zero CVS Commands to Run
My favorite thing about using Time Machine on my Macbook Pro is that I never have to use it! Once you set it up initially, it's good to go. I believe that this really saves me time in the long run. When using one of the other two systems, you are always editing something and then flipping back to commit your files and push them to the repository. Even if you only push once or twice a day, those minutes add up! Sure, you probably have either a quick command-line workflow or a super easy-to-use gui dealing with these things, but the time spent on this is in some ways unnecessary. It can be especially burdensome if you find yourself running into conflicts, cherry-picking files in a huge directory structure, or dealing with branch-merging issues. Git and svn can be great for distributed teams building software together, but what if there was a simpler way?
Single Workstation Philosophy
Ok, this is where things get a little controversial. I'm going to argue that one of the key advantages of using the "ghost drive" over git/svn is that it lacks the ability to share code easily. This is the basis to the single workstation theory: you don't need to share the code across machines. You might be thinking, "This is fine if your company has 1 programmer, but what about our team of X people? How could we all be productive when only one of us has a computer?". Well, these are great questions to ask. See, it's not that you have 5 people on a team and only one computer. Each has his or her own laptop, but then there is another workstation- called "the workstation". Each person can test things out, look things up, and make little prototypes on the personal computer, but all production code is written on the workstation. You can see how git and svn could undermine this paradigm. People could just clone the repo anywhere, and eventually they would get lazy and probably start committing code from their own computers. And then everything reverts back to "regular development", the vanilla scrum that happens when you just let each coder go and see what happens. The point of having a single workstation is that it brings everyone together. It is eXtreme programming taken to an extreme. People cannot get lazy and say, "this part is too easy for us to pair on" because everything must be pair programmed, or at least be written at the common workstation. This works get people working a more collaborative, XP-like environment, and your team will then see the benefits of XP more vividly.
I admit that this setup will not work out well for all situations. If you have a huge team of more than say 10 people (with 5+ coders) then one workstation can get pretty crowded. However, if this is your situation then you might want to consider breaking up the project into two or three separate projects with smaller teams that can really focus on their own piece. If you actually do have a distributed team with people who work remotely and never see the office walls then this system really won't work for you. It is my firm belief that employees are way more productive in the office than coding from home. Pair programming, face-to-face communication, seeing how others are coding parts of it- all these things require the coders to actually be there! However, at times companies have the opportunity to hire master-level, sometimes even "famous" in their industry programmers who insist on working remotely. In my opinion, this is the only time remote coders should be considered and even then I don;t think it would be wrong to say "sorry, but no" to this person. Finally, I'll point out that Time Machine is not meant for going back to previous versions of your code in the way that git and svn are. Reverting your code can be tricky, and Time Machine is really just meant to backup the codebase in case anything unlucky happens to the single workstation.
I'm interested to hear what people think about this. I know many coders who love git and would never think of coding a project without having a repo for it, but this is just how my last workplace stored the code. It was a refreshingly new experience for me, and maybe it could be for another team of coders as well.
The posts on this site are written and maintained by Jim Lynch. About Jim...