A few years back I was working in a shop that was producing software but was not really a software shop. We were a communications studio (which is like being a marketing firm but broader in scope) and a small part of what we did was offer a content management system which is what I worked on. It was my first programming job ever and for large swathes of time I was a one man team. I was young, inexperienced, and overconfident in my abilities.
At the end of every day if I needed to take some work home I would zip up a copy of the source files and email them to myself at my home address. When I got home I'd unzip them, do what I needed to do and then zip them up again and email them back to my work address. Sometimes the files (with test-data etc) were just too big for email so I'd burn a CD. Or just send a few of the files. Only the ones I needed. The source code was on a server somewhere that was being backed up so I figured I didn't need to be that worried about it.
Then we had a client that needed something different so we copied the source code into a new solution, created that feature, deployed it and moved on. Then another client, then another. After a while we realized that some of the features we had created for Customer A could be just as valuable to Customer B. So we sold it to them.
By then we had roughly 25 copies of the source code, all slightly different. All in sub-folders on a server. We found the one version with the required feature and then copy-pasted it into the other clients source code. It took a bit longer than expected. Things worked a little differently between the two versions but we got there. After all, it was cheaper than developing that feature from scratch had been.
So we started to canvas all of our clients. We showed them features that they didn't have and offered to sell them at a fairly reduced price. We copied. We pasted. We made a little money. We started getting requests for enhancements to these new features (now called modules). Some of those enhancements where bug fixes which needed to be applied to each different version of the software. Many of our clients had no support agreements but we did it for them anyway. We were a communications studio after all and we had a long-standing relationship with those clients.
Then we started to have have modules that relied on the existence of other modules and things got scary (as if they weren't before). Now we'd add a new feature or fix an innocuous seeming bug and something that worked before is now broken. Something seemingly unrelated. The menu was working fine last week, said one client, but since adding in the photo-gallery the contact us page won't email. Can't we go back to the version we had last week? Hah! As if I could control time like that.
That story is true and it brings me almost to tears just writing it down. When I left that job the guy who replaced me put in a Version Control System right away (before I left actually). It's been a few years but I believe that he has tamed the 50 or so versions I had right down again. If he promises not to hit me I'll buy him a beer and he can tell me about it.
He knew something that I didn't. A good Version Control system does let you control time, space and custom configuration like a serious code ninja. Used wisely a good source control system will allow you to:
- Keep track of the changes you make to implement a specific feature or fix a specific bug
- Stamp a specific version of your code base so that you can get at it later (i.e. Which version was deployed to client X on date Y by previous employee Z?)
- Make Restore Points in your code-base that you can return to at a later time (i.e. To fix a bug in version 5.4 without saying "update to the latest version")
- Make sweeping changes safe in the knowledge that you can go back to how it was before if it doesn't work out
- Work effectively with multiple developers (and other people producing artifacts like artists) by keeping track of who changes what and merging changes to the same file
- and more...
If I could give a starting developer one piece of advice it would be this one:
Use a Version Control System!
It doesn't matter which one. Pick one, the skills are all pretty much transferable and installing one of the free ones is generally pretty easy. In fact, if you just want to play around there a few places online that will provide you with a free Subversion or GIT account. If you are interested in Team Foundation Server then you might create a new CodePlex project.
Here's a few links to get you started:
- Better Explained - A visual guide to Version Control This article gives a good overview of what Version Control is and how it works.
- Eric Sink - Source Control HOWTO Eric is the founder of SourceGear, the company that creates the SourceGear Vault Version Control System. The link goes to a series of articles about Source Control and explain many of the concepts in greater detail
- Kyle Bailey - Review of the Check-In Dance If you are working with a team of people or trying to use Continuous Integration then you'll definitely want to check out the Check-In Dance. This is a process for ensuring that what is in your Version Control System will always successfully compile (and pass tests etc.). That means you won't ever check out a version that's broken and waste time trying to fix it. There's a link to a short video on here as well.
- Streamed Lines: Branching Patterns for Parallel Development There will come a time when you want to branch. The usual advise straight up is don't. Now assume that you need to. This paper explains several patterns for branching and merging software depending on what it is that you want to do. It's heavy reading but well worth it before you find yourself in merge-hell.
- Wikipedia - Comparison of revision control software Compares various free and commercial Version Control Systems to enable you to make a selection.
No new comments are allowed on this post.