Shared publicly  - 
 
Is Automated Backup More Important Than Version Control?

I got blasted at the last Front Range PHP User Group (FRPUG) because I had said I was not using version control with a personal project I had been working on. In the eyes of +Chad Robertson and +David Stockton seeing as I've been a developer so long, it was an inexcusable crime I had committed. My defense was that I used the continuous backup solution Backblaze. "It even supports file versions!", I pleaded in vain.

Licking my wounds and muttering to myself, I realized that I've worked at a few software shops that had version control but not automated backups. Which is more important: automated backups or version control? It goes without saying the correct answer is, you should have both. If you could only have one, which would it be?

The winner is, automated backups, if you are a team of one. If you are a team of one, version control is nothing more than a fancy backup. If you were to lose your computer and all its data, the productivity lost from having to setup a new system versus the productivity lost from not using a version control system are much larger. I say this because I went a whole year without version control and it never caused me a problem, not even once.

Once you have a team of more than one, you've got to use version control. The amount of time you would save using a version control system over the time you save from having a good backup system skews heavily in version control's direction and that's just with two developers! I'm sure it grows exponentially with each person you add.

When I was a consultant for Zend, software shops would pay a lot of money to have me come out and visit them. Some of these shops, and this was not that long ago, did not have version control. That to me is just lunacy.

If you have to chose between the two, is automated backup more important than version control? No, unless you're like me and have no one working with you. At least that's the argument I muttered under my breath while at FRPUG. The real answer is that you should have both.

I'm willing to guess that at least 25% to 40% of software shops out there don't have automated backups running on their developer's computers. I bet if a developer lost a hard drive they could be out of commission for 2 or more days just getting the computer back to what they need. Then there is all the uncommitted (or not pushed to another repo if you're using a decentralized version control) code that was lost.

You have version control, but do you have automated backups?

Edit: I'm assuming the backup is not just to the same computer. It should be off site if possible.

#programming  
2
Sam Hennessy's profile photoA.J. Brown's profile photoDavid Stockton's profile photoAndrew Strickland's profile photo
8 comments
 
The simple truth is that both could be had for free and with little effort. For any developer to say they don't need version control is pure laziness. What happens when you leave? Or when you pull on a new developer? Just because it's you doesn't mean you won't need to back track.

Github offers small repos with 5 developers for startups, students, and small businesses. Bitbucket offers free private repos. 

Google drive provides up to 25GB free.

Saying one is more important than the other isn't the mind set you should be walking away with. What you should be saying is "does the cost out weigh the benefits?" and when the cost is $0.00 I think you need to reconsider your perspective.

My concern with you saying that was the same when you announced that you weren't doing any unit testing either, yet you were speaking to a room of mostly apprentice level developers. They basically heard from a knowledgable and experienced source that doing the wrong thing was acceptable. That's where it becomes irksome.

As a mentor and example you should strive to instill junior developers with the right tools and practices, not the wrong ones.

#mytwocents
 
This is some kind of karma. I just type you out a long comment that I lost in the Google+ UI. +Holly Hennessy  says to me "did you have a backup?"

I didn't do these things in my side project correct. To work on this side project I had to take time away from my family. Automated testing in PHP projects takes a great deal of investment. This is especially true when you talk about databases. I felt a great pressure to spend my time wisely and felt I had to fiercely justify my time.

I agree that in some ways I was/am a bad example but I did clarify my reasons. I do feel I was an example of someone who when out and built something. I'm happy to be know as a good example for that over the other.

I'm also a little stuck when it comes to being a good example. I'm not going to lie and say I did do these things when I didn't. I'm just the example I am, I can't make life choices based on being a good example to a junior developer at a user group.

I do appreciate your thoughts Xander. It made me think and I like having people that will keep me honest.

#imabadexample
 
Unlike Xander, I don't take issue with not unit testing code. Those of us who've done unit testing know its value, but it's not without cost. If you're doing a solo project and you measure costs by time spent, unit testing can be more expensive than you can afford upfront. The cost of NOT unit testing, however, increases over time in the form of technical debt. You eventually have to pay the piper, so all you can do is defer that cost for a while.

Good code will still be good code even if it's not unit tested. Untested bad code will lead to much more firefighting in a production application. But if there's an upper limit on your total available time in a project, releasing a fully-functioning but somewhat buggy product is going to be better than never releasing a half-finished, well-tested product. Every. Time.

The source control vs. automated backups argument, however, is a false dichotomy. They're not mutually exclusive and they're not expensive in terms of time, effort, or money. Source control is free and backups are a fraction of the cost of deploying an application. If you can afford to launch an application, you can afford to back it up. Both can be set up in minutes.

Untested but correct code doesn't suddenly stop working. But servers crash, hardware fails without notice, and humans make mistakes while coding. Failure to prepare for these scenarios leads to failure—not if, but when.

The risk of not unit testing is buggy code and unpredictable behavior. The risk of not using source control or not backing up your production environment is the immediate and irrevocable destruction of your business.

Always use source control. Always make (and test!) backups. (Almost) always do unit testing. Never put your business at risk because it might save you a few dollars or a few hours.
 
Version control is not just about backing up versions of files. It's also about change management and history. If you only use it to restore old version of files, you're using only a fraction of what's provided.

I'd also add that a Distributed VCS like git provides "automated backup" and version control all in one.
 
+A.J. Brown , don't forget this is not a real scenario just a thought experiment. Saying that, how is it automated? If you have someone who has not pushed for a few days. There goes that work. Does your shop have automated back on all developer boxes? 
 
Any code that's not shared certainly has no backup, but the point is that proper use of a DVCS gives you a high enough degree of "automated backup" that the importance of it over version control is irrelevant.
 
+Sam Hennessy I don't think I've got a lot to add to the discussion at this point beyond what +Greg Hines and others have said. Of course it's better that you have automated backup than not, but at the same time, at FRPUG there are a lot of people who are just starting out with development. Both version control and backups are important. Version control allows you to do things you cannot do even if your backup system provides for the ability to get back different versions (which I don't think was said or perhaps not made clear at the meeting). 

The time investment in starting version control is minimal. The time taken to download mercurial or git and set up a bitbucket account (for free) is on the order of a couple of minutes. The time saved by using version control when you're doing deployments over something like FTP or file syncing is huge though.

If you're building a feature on your site that takes more than a short while and meanwhile someone finds a critical bug in your site, if you're using version control, it's trivial to switch over to the "live" branch and make a fix and then proceed with your feature. If you're only using automated backups with file versions, at best, your ability to make these changes is a complicated and easy-to-screw up dance of restoring the version that's deployed (assuming you can remember which one it is), making changes, deploying, restoring back to the previous version which is really the current version with the new feature you're working on. That sounds like an enormous pain that could easily be avoided.

I guess the surprise expressed by Chad Robertson and myself was that you're a senior developer and should know better -- do know better. The distinction between a single developer or multiple on a software project is minimal though. As others (and you) have said, once you get another developer, having version control is critical. I argue that it's critical the moment you started a project that wasn't a throw-away one-time-use script.

One additional argument for version control over just your automated backups is keeping your project clean. If you built a piece of code that you find later you don't need but suspect you might in the future, the temptation is there to leave it in the project. Your automated backups only do versioning for the past 4 weeks which means if you deleted it and then didn't need it until after 4 weeks, it's gone, so leaving it alone promotes less "code loss". With version control you could get it back at any point in the future, regardless of how long between deciding that you don't need it now and later deciding that you do. 

Combining the two gives you the best of both and for minimal cost. For $5/month + free/month, you've got backups and version control. I don't know why you wouldn't use both.
Add a comment...