Source Control Best Practices (Part 2 of 2)

The primary purpose of source control is to share a common library of
source across developers and check files in and out of that common
library to enable collaboration.

Most application developers understand the importance of source
control. Unfortunately, I have had the unpleasant experience of having seen
first-hand the perils of not implementing source control correctly. I am sharing my story in the hope it may help you understand source control better and avoid the productivity drain that can occur when your team has to waste time fighting against source control rather than using source control as a valuable development tool.

On one project I was on, the team implemented improper source control.
I tried to help them understand that this was not the proper use of
source control software, but I was a late-comer to the project and
procedures were already established that the team was unwilling to change.

At any rate, I don't know where the team got this theory, but their concept
for source control was that every developer should have their own branch of
source code. The concept was that any one developer should be able to make
changes to any area of the system without holding up any of the other team
members. This was supposed to make our team more agile and efficient.

We ended up having the following results instead:

1. The primary purpose of source control was effectively negated.
Instead of checking in and out of a common library, we each checked
in and out of our own, isolated library.

2. Creating even an interim build was a monumental effort. Bringing our
code libraries together was a painstaking (and manual) task where we sifted
through which changes to apply from each developer. This process took
literally days to complete and often resulted in the introduction of bugs and
issues because it was so difficult to create a good version of the source.

3. Deja Vu all over again. After a common build was eventually completed,
each of us was required to create our own branch from the common source
and we would begin the exercise of being out of sync once again.

Let me give you a quick example:

I have taken a messy module with 800 lines of code
and paired it down to 200 lines of code, in doing so I eliminated 3 redundant
methods entirely. My colleague made a few small changes to his branch of the code,
and checked these changes into his branch. When we go to do the build, the
"build master," the poor developer stuck with bringing all of the various branches
together for our build, looks at both of our versions of source and sees that they
are different. How does this "build master" know which code is correct? She is under time pressure to get the build out, she sees that my version is missing 3 methods, so she decides that the source with the most code is the correct one, starts with that and picks and chooses the differences that appear to make sense to create the version used for the build. When the build is done, and I get the new "master" copy of the source, I look at this module and all of the clean-up work that I did was gone. I either have to blow it off, or do it again.

Each developer should be in control and have responsibility for making sure the
correct source is checked out and checked back in. This should not be left up to
a single developer at the end. No matter how good that developer is, it is
simply too daunting of a task, especially in crunch time, to have to go back
through and make judgment calls about other developer's code.

Needless to say, this process of creating a branch for each developer killed
our productivity, caused in-fighting amongst the project team, and absolutely
killed moral.

In the end, this project was delivered very late, with very few of the
promised features. I attribute most, (if not all), of this project's issues to improper source control procedures.

Please see my previous post for how to use source control and branching effectively.