Tools of the Trade (Part 2-Source control)
Source Control
When you are out driving on a gravel road and no one else is around, you can drive down the center of the road, honk your horn to the time of the rock and roll, you can weave from side-to-side to avoid pot-holes. Sure it is dangerous, especially around a blind corner, but the chance of something tragic occurring is small as you are the only one on the road.
However, in a city on a crowded freeway you must stay in your lane, you must keep up to the car ahead of you and you can’t change lanes without first checking your blind spot. If you make a mistake then not only are you in trouble but so is the person you hit and the 5000 people behind you rushing to get to their dentist appointment.
It is like that with source control, the more people on the team and the more geographical diverse your team, the more important it becomes.
Taken from wikipedia…
At the simplest level, developers could simply retain multiple copies of the different versions of the program, and number them appropriately. This simple approach has been used on many large software projects. While this method can work, it is inefficient as many near-identical copies of the program have to be maintained. This requires a lot of self-discipline on the part of developers, and often leads to mistakes.
Sure analogies are great, but why do you need source control?
Take a simple software department that is supporting the companies website. There is great hoopla and celebration when the site goes live. The long hours and the frustration with bugs is well worth it, the site is slick, it wows the president and the money starts to flow. Everything is grand and people take a well earned vacation.
Upon returning you find that everyone is happy but the marketing department has just come up with a great new campaign for boosting site traffic. You sit down and go through the requirements and say no problem we can do this in two months. Back to the cracker-jack development team and you start coding.
Trouble starts brewing when a new browser is announced and suddenly you are getting calls from your support desk that customers can no longer pay by credit card when they use the new browser. CRITICAL ISSUE-STOP ALL DEVELOPMENT AND FIX IT!
Problem. How do you know what code to use? You are half way through new development and the website is unstable. Can you find that CD that had the code from go-live? Did the developer remember to back up his copy when he upgraded to Vista?
Luckily you’ve been using source control and can get the code from go-live and make the changes. Problem solved: you are a hero!
That is just one instance of when source control is essential. Some other scenarios:
- Configuration Tracking: Multiple customers with customized additions to your core product
- Rollback ability: a new developer decided to go through and fix up all those ‘memory leaks’ and ended up breaking the code.
- Disaster Recovery: centralized location for backup and disaster recovery
- Collaboration: sharing of code amongst geographically separated team
- Traceability: someone found an easter egg in the software and the CTO is not happy. Who gets the blame?
The list continues and keeps on growing. Show me a team that doesn’t use source control and I’ll show you a team that is bound to be working many long hours or is just a single guy slaving away in his basement.
