| « Happy New Year: 2010 Goals | Painless Spec and Schedule Development » |
If you ask most developers about source control, they’ll agree that it’s a wise thing to use. They’ll insist that they think it’s important. But yet, why are so many companies out there still not using source control in their projects? A good number of companies that I’ve worked with failed to make use of source control, resulting in issues that would have been trivial otherwise. In this article we’ll explore ways to make sure that if your company isn’t using source control, that you can help make a change to this policy.
Source control doesn’t need to come from the top
The first oft-considered misconception is that source control must be endorsed by upper management in order for developers to use it effectively. This is 100% incorrect. There are a number of ways that developers can make use of source control, even if management fails to embrace it, or rejects it altogether.
Subversion can be set up locally on most systems; a repository can be created in a central location and, as long as you do a regular backup, your repository should be secure. Git is designed to have the repository locally by default; this makes a great source control system if you have total ownership of the project.
Bear in mind that the point of version control is two-fold: first, to make it easy to collaborate with a larger group, and second, to help version your code so that you can see changes over time and possibly roll back if there are problems. Bear in mind that in larger teams, personal repositories won’t work, but in smaller teams or in places where you own your project, you can use source control.
The person that needs convincing is probably not the upper management at all
Many of my friends work for “creative firms” that are marketing first, development last. These firms are set up to provide excellent marketing to the clients, but more or less may not care about the development team. While this is often frustrating, it can also be a blessing in some ways.
As long as the team lead can be brought on board, placing code into a repository can be easy. If the team is larger than three or four people, using Subversion or another VCS is crucial; more likely than not there will be other owners of the project and everyone will need to collaborate.
The cool thing is that most of the time upper management types don’t care how the development is done as long as it is in fact done by the developers. Thus, convincing upper management isn’t the way to accomplish the goal of implementing version control.
Version control is not a silver bullet
A few times in my career I’ve heard someone say something along the lines of “oh, if only we had been able to use version control. Then that project would have been on time.” Bzzt! Wrong.
It might seem obvious that version control is not a silver bullet but it is often treated as such. It’s such an important and ubiquitous tool that it’s easy to think that having it will solve all development problems. But it’s not a replacement for good management, good time management skills, and solid development practices.
Version control should never be cited as a way to make development faster. It doesn’t generally do this (with the exception of generally preventing developers from accidentally overwriting someone else’s work, causing duplication of efforts).
Version control is best utilized before a crisis
Again, this might seem obvious, but there’s a harsh reality amongst developers: most of the time, when they feel as though they’re not permitted to implement version control, have a tendency to say “Well, next time code gets lost, that’ll teach ’em.”
Don’t think like this! It’s just going to ultimately create more work for you, the developer, when the management wises up, realizes that they need version control, AND that they need the code rewritten that was ultimately lost. You’ll have double the work, and even though you’ll get what you want, you won’t like it.
Fight for version control consistently BEFORE a disaster. This will improve your chances of having it in place prior to some disaster striking.
Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP
Posted on 12/23/2009 at 8:00 am
Les wrote at 12/23/2009 8:58 am:
What would you suggest are the best tools to integrate version control along side your server – apache of course – so there is seamless interaction?
I hear of webDAV but never really got into it. Also, how does this affect unit tests?
Tomaž Muraus (@KamiSLO) wrote at 12/23/2009 9:48 am:
I still find it hard to believe, that there are companies where more then one person is working on the code at the same time and they are not using any kind of version control system.
@Les: What you mean with “integration”?
If you mean accessing / viewing contents of your repository via your web browser, you could use webSVN.
Or take it to the next level and use a project management tool which supports integration with different kind of version control systems (redmine, trac, etc.).
Joel Clermont (@jclermont) wrote at 12/23/2009 10:42 am:
I insist on using source control even if I’m the only developer on a project. It makes it trivial to jump between machines for development. It makes it possible to track your changes (and even retrace your steps for a detailed invoice). Plus, if you’re really gutsy, you can give a project manager or client access to view the svn logs on a website and let them monitor progress in real time.
@thomas
That is what I was meaning, something that would work seamlessly with the server. I’ll take a look at webSVN, thanks.
Giedrius wrote at 12/24/2009 5:42 am:
I agree with the comment, that even if you are working alone, you should use source control system. It’s very good way to keep track your work.
Thanks for nice article!
TQ White II wrote at 12/24/2009 12:13 pm:
Contrary to your view that personal repositories don’t work in a team, I always keep a local repository. At minimum it is a grand ‘undo’ buffer. At best, it allows me to try things that I may not want involved in the real code base. Git is great for that.
Andy Rockwell (@solidphp) wrote at 12/25/2009 9:19 pm:
Smaller companies often don’t understand the full benefit of using version control or don’t understand version control at all.
From my contract development experience, the biggest offenders are companies who do most of their business in local markets with developers in house. These companies stand to benefit the most from proper version control and simply don’t realize it.
What I do personally is offer to install a nice Ubuntu LAMP stack + version control for them locally, setup the project in version control and train other developers to use it as the project progresses. Ubuntu makes it really fast and easy so I offer to do it for free.
Do this and at the end of the day you’ll end up with very happy customers who trust you and keep coming back with contract after contract when they can.
Stephen Cox wrote at 12/28/2009 5:28 pm:
Project that i won (meaning only I am working on) I do not use version control. I rely on TM backups. ;)
Jesus.. sorry for the typos. Just reread my comment ‘above’. Was typing too fast.
| « Happy New Year: 2010 Goals | Painless Spec and Schedule Development » |