At our company we have started outsourcing some of our development.

This has worked somewhat well. However, we are having a hard time getting them to properly use version control. They are familiar with SVN and know how to use it. However, for some reason they don't commit regularly, instead they work with 16 things simultaneously and make a huge commits every 2 weeks, if we are lucky maybe with a few comments. Which makes it very difficult to both following and review their work, collaborate and also fix bugs. I have tried to explain to them to do their work as one small task at a time and regularly commit each of these with appropriate comments. Without much success, either they don't understand the concept or they are lazy.

My question is, what would be good guidelines describing how one should work with version control, not from a technical perspective (they know SVN), which seems to be the only thing I'm finding online, but from a development/collaboration/project perspective?

  • 1
    tell them to read the Commandments scottonwriting.net/sowblog/archive/2008/11/13/163320.aspx
    – Mithir
    Apr 12, 2013 at 8:43
  • 2
    By "outsourcing", you do mean that you pay them for performing certain tasks, right? Why can't you simply require the task order and commit frequency as part of the contract? Apr 12, 2013 at 8:44
  • @Kilian Foth: The tasks are rather large (e.g. implement interface y for system x) and is up to them split it up into sub-tasks.
    – ronag
    Apr 12, 2013 at 8:46
  • 1
    @gnat: Reformulated question.
    – ronag
    Apr 12, 2013 at 8:54
  • 1
    If you don't specified in your contract beforehand that you expect daily commits, and only compilable commits, then it will become hard to enforce that afterwards. These are non-functional source-code quality requirements which are often forgotten in contracts.
    – Doc Brown
    Apr 12, 2013 at 11:09

2 Answers 2


The firm is an outside company, so you can't really dictate that they follow a certain philosophy, workflow, etc. internally.

However, you have hired them, so what you can control is the requirements for what they produce. You don't need to convince them "this is a good process for programming"; all you need to say is "this is our company's process, and we expect what you deliver to conform to it".

Clearly outline your expectations, such as:

  • The frequency of commits you require.
  • Limitations on the number of changes in a single commit.
  • The way changes must be documented.

You don't really have to justify why you want to do these things. However, it is likely that they will discover the benefit of these practices once they start using them.

Update I think Karl Bielefeldt makes some good points as well. Ultimately, it depends on what kind of role the outside developers are playing. There is a continuum: from contractors who work on site and are practically indistinguishable from employees, to an outside company that simply delivers a finished product to your specification.

  • You can't make anyone do anything, but you can force them to suffer the consequences like not getting paid.
    – JeffO
    Apr 12, 2013 at 16:46

In effect you are asking them to share unfinished work in progress with you, their customer. That's not very common in outsourcing arrangements, and comes off as micromanagement. Even if it's only partial outsourcing, like they are considered employees of your company, but are located in another country, remote sites usually have a lot of autonomy with work in progress. Also, some cultures are especially sensitive about presenting a good face.

On the other hand, smaller commits are easier to work with after the fact. You might have better luck with a different branching model. With a DVCS, the remote team can have their own private branch to commit all their work in progress, but they can choose not to merge that branch until the task is presentable, i.e. at the end of the iteration. You then get all the history, but they save face by not having to share incomplete work. I don't know if that's technically feasible with svn or not.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.