Bad Source Control

I work on small team with ancient source control* – namely SourceSafe. It’s horrible. Why? Mainly because it slows the team down – tremendously.

We work synchronously. Two developers can’t work on the same code because they then have to also be integrators – figuring out how to meld their code together – and you always miss something. In an environment where there are no code tests and everything is dynamically linked, you don’t find out what breaks until that code is run – which could quite literally be weeks later due to the sheer size of the application. When the bugs are discovered, the cycle starts over, increasing the time to when the bugs are fixed.

Commit History
Sometimes you break something – or someone else breaks something. Trying to find out what broke by going through the history is tedious, especially when there’s no good method of representation. In a good source control, you can go back to tagged versions that worked and compare files. If not, you’re literally sifting through tons of commits trying to make out what is what. That’s time lost.

Commit Messages
I love Git. One reason I love it is because it basically forces you to provide a commit message. You can skip it, but you will always go through that prompt screen / have to go out of your way to say that you have no message. Some VCSs make it optional (*cough* SourceSafe *cough*). When looking through commits that have no messages, you have zero clue about what changes without comparing commits to each other.  A simple message such as ‘fixed misspelled word’ could save me minutes in terms of comparing two files and scrolling to the actual change to see what it was. Granted this is also do to the person not adding a message, but the wall to prevent them is not there.

You don’t know how awesome branches are until you don’t have them. Spiking something? Create a branch. New Feature? Create a branch. Getting code from someone else? Create a branch. Different release versions? Create a branch, (layman’s way). When you don’t have branching, you revert to copying your files so that you have a backup. Which takes time, a lot of time.

Getting the latest version
Want the latest of code on the central repository? Depending on how it is setup, it could take you upwards of 5 minutes to go through all the project folders to make sure you don’t overwrite something that you might have locally. “git fetch” is an amazing thing.

So what’s my point? Poor version control systems slow teams down as time ticks away. They don’t allow for simultaneous progression of the code base and are painful to work with. Even if you have a good VCS locally, you still have to integrate with the central code base and work with the rest of the team. In the end, small development teams will lack the advantage of agility. Time is money. When you lose time, you lose money.

*Believe me when I say that I’ve pushed for changes.

Leave a Reply

Your email address will not be published.