0 Comments

This article deals with the topic of introducing your clients to the use of source code control in the software development process from the viewpoint of a small software consulting company.

I recently participated in a very interesting discussion on the Utter Access Forums. Originally it was about the rate of comments in source code but soon digressed into related topics as code quality and using source code control for Access development.

UA-User GroverParkGeorge replied with some very interesting comments to my deliberations that source code control voids several arguments for adding comments to the code. Here are the most relevant excerpts:

“If YOUR consulting business includes projects for large clients, or for your own organization, all of which have a budget for all of the tools you need, and all of the documentation you want, then it would be reasonable to obtain and use things like Source Control tools.

If you are taking on a $5,000 project with an existing Access application for a three person customer shop, it's hard to insist that they should provide those tools for you before you take the project.” (full post on UA)

“I've discussed various approaches to Source Control with clients over the years. Most of them who are not deeply involved in software development themselves tend to be reluctant to delve into it, though. And that's just a fact of life with smaller consulting clients.” (full post on UA)

George, thank you very much for these interesting comments. Looking at your objections per se they are sensible, valid, and a strong argument against SCC in smaller projects.

However, I use a totally different approach to introduce source code control at my clients and, if I haven’t misunderstood the objections, this approach might weaken their argument.

Using SCC in client projects

I do not talk to clients about source code control at all. - Unless they got developers employed themselves, who are going to work with me on the project at hand (more on that later).

I’ve got all the required tools licensed to my name. So I do not need to discuss licensing with the client. If I work on project from my office then everything is settled already now. The client will get the completed software delivered. He will never be in contact with SCC in any case.

It’s a bit different if I’m required to work at the client’s location, but not too much. Most modern source code control systems can have their backend installed in the cloud. So there is no need for installation on the client’s site. I only request permission to install local/client tools on their dev computer and to access my (SCC)-server via the internet. - BTW, this is not limited to SCC but includes other tools as well. - If they would refuse that, I would actually consider to decline working with them. - However, no client has ever done this yet.

Of course, I assure the client that all tools I’m going to use at their office, are properly licensed to my name and that I’m legally allowed to use them in this project.

(Side note to Ivercy customers: This is perfectly ok with Ivercy licensing. Ivercy is licensed per developer. If the developer is covered by a valid license, we do not care about where the developer is located and on whose computer he is working on.)

Now, for the case that the client has got his own developers working on the project as well. In that case, I cover all the licensing for the required tools as well. If it is a big (read: lucrative) project compared to number of developers, I just absorb the cost.

Otherwise I include the cost for that in my budget for the project. As my providing of the required licenses is only temporary, for the duration of the project, the costs are usually tiny compared to the total costs of the project. There was never any discussion of costs in this regard.

In this situation, it is somewhat more difficult to convince the client’s project management to use my (SCC) infrastructure, as their project is somewhat dependant on it. - I convinced most clients pointing out that they haven’t got much to lose. They can continue to work without SCC at any time. They only would have to come up with some other means of synchronizing the collaboration between all developers of the project. - Which is a massive pain of course, but one they would have right from the start if they do not want to use SCC for their project.

This has been declined by a couple of clients over the years. - All of those opted to purchase, install, and use their own SCC-Infrastructure instead of mine for their project. Which is all the better, as I’m not responsible for it then. J

The most difficult part is to convince other developers to use SCC in a project if they haven’t done so before. The argument of the collaboration issues is usually convincing enough, even in this case.

If it should be not sufficiently convincing, I just need to remember a past project.

15 years ago I worked on a pretty large Access project together with up to 4 other developers without using SCC. Synchronizing all developer’s changes to a coherent, working release for the end user was a massive pain each and every time. It frequently caused problems with the release, because we missed some “minor change” from someone when integrating all changes into the new release.

More than once we missed the resulting bug during testing - No automated unit- or regression-tests back then either. Naturally, sooner or later the bug was discovered with the application in production. It was then causing significant additional costs due to the unplanned effort required to analyze and fix the issue and finally roll-out a bug-fix production release.

If some (potential!) client really wants to go down this road, he has to do so without me. I will happily walk away from projects like these.

The financial cost of using source code control

At the beginning of this text I wrote, I got all tools required for SCC licensed to my name. Let’s look closer on that side of the matter now.

We use Sourcegear Vault for version control internally. Vault is not free. (Unless you are a single developer.) We used the Microsoft source code control plug-in for Access integration until 2015, but this is only supported up to Access 2010, so it is of limited use today.

Of course, we now use Ivercy in our own projects for SCC-Integration into Access. Ivercy is a commercial product. For the sake of discussing the costs, I just include the regular price for an Ivercy-5-User-License.

I’ll break down and compare the cost of using either Vault or Microsoft Team Foundation Server Express Edition, which is free but limited to a maximum of 5 users.

  sg Vault TFS Express
Initial licensing cost for SCC-System (5 user) $1.710,10 $0,00
Initial Licensing cost for Ivercy (5 user, incl. 1yr support) $450,00 $450,00
Total initial cost $2.160,10 $450,00
Optional - SCC-System updates&support (for 10 yrs) $3.000,00 $0,00
Optional - Ivercy updates&support (for 9 yrs) $1.260,00 $1.260,00
Total cost after 10 years with full maintenance $6.420,10 $1.710,00
     
~ Cost per year (5 user) $642,01 $171,00
~ Cost per month (5 user) $53,50 $14,25
~ Cost per month per user $10,70 $2,85

 

Side notes:

All prices are approximate. Not included are the related costs for hardware and operation system, their maintenance, and internet connectivity.

In this comparison, the price is obviously in strong favor of TFS-Express. But Sourcegear Vault is an excellent system and in my opinion easier to use. This is particularly true if you used Visual SourceSafe in the past. So, there is even a point to spending the money for 5 users or less. But, assuming your requirements exceed 5 users at some point in time. With Vault you would just buy another license. With TFS however, you cannot use the Express Edition anymore and would need to buy the appropriate number of TFS licenses.

Conclusion

Of course, the initial cost of introducing source code control for the first time is considerable for any small business. If you only count it against the revenue from the very first project you plan to use it on, the cost might be prohibitively high at first glance.

But that is only part of the picture. If you are a software development shop, you will use source code control over and over again on many projects. Calculated over a long time (10 years in the above example) the cost will become almost negligible.