The cost of not using version control

Last week we published a blog post my colleague Hannah wrote on our library development process. The process included the use of version control to manage regular library revision backups and also merging of multiple user developments into one central repository.

The purpose of this blog post though, is to quantify the potential cost of not using revision control in model library development whatever the simulation tool is that you are developing a model library with.

Single developer case

Take the case of a single person who is developing a model library on their own.

Multi-user development integration is not an issue here so we can eliminate that consideration for now.

As the library development progresses, models change, get improved, bugs are found and we might go down some development “blind alleys” from which we have to reverse to go back to a point of the development where the models give sensible results again.

Using version control tools, this is easy. You simply “rewind” your local copy to a previous version stored in the repository and carry on from there. If you named and commented each revision appropriately it will be easy to choose how far back to rewind the library version. Call this on average a 30 minutes task.

Your alternative to using version control is to make “copies” or “snapshots” of that library on a hard drive. Naming can soon become confusing and keeping a log of what changed, where it changed and when, becomes an extremely high maintenance and error prone task.

On average I would estimate 3 hours of work to find the manually backed up snapshot of the model library that gives you results that are good again and understand exactly what changed. That’s on a good day where only maybe 1 or 2 models have changed since the “good” version was stored. So, call this on average a 3 hour task with the potential to increase to 2-3 days.

In terms of man hours it’s going to cost you 6 to 48 times what it would have cost you using version control, and that’s for rewinding a couple of models for a single developer.

Bear in mind that most version control tools are free, so the cost of purchasing these tools really does not come into it.

Group of 2 developers both working on a common library

Take the single user case and multiply that time taken by the number of “rewinds” each user has to perform for either backing out of a “blind alley” or purely to check past version results. The numbers really start to get scarily big for a team of even 2 people…

…but it doesn’t end there!

You’ve made changes to a model or group of models on your machine and you now need to notify your colleagues and agree a merge/model exchange point so that you are all re-aligned.

With a version control tool, this can take a few seconds and manual merges might take a few minutes where the tool cannot automatically merge changes made by two or more users to the same section of code in model, for example.

Figure 1: Process schematic for a 2 person library development team using a version control tool such as Git or TortoiseSVN.
Figure 1: Process schematic for a 2 person library development team using a version control tool such as Git or TortoiseSVN.

When manually performing a merge of different versions/copies of the same library, you will need to decide

  • Where to exchange the libraries.
  • Make a list of which models have changed. Even just name changes can cause a lot of grief if you need to manually update links.
  • Help each other out by giving additional information where required.
Figure 2: Process schematic for a 2 person library development team using manual version integration.
Figure 2: Process schematic for a 2 person library development team using manual version integration.

How long would we say this process might take for a simple case? Remember a lot of people are working from home at the moment so there goes the easy face to face dialog with the person usually sat beside you. Half a day to a day for one or two models that don’t affect many other models in the library? That might not sound very long but this is a best case really.

If we look at it as a multiple of the time spent performing the same process manually vs. using a version control tool we see that just updating each other’s library will take between 6 and 13 times longer with the manual process!

Let’s not bring in the amount of time that is also required to manually retest all experiments affected by the model changes unless you can bear to even think of that. The time savings estimated so far should make you want to implement a version control tool if you aren’t already using one.

Hopefully you get the picture. If you are a manager, you may even want to multiply that time saved by hourly salaries or subtract the time from typical project delivery estimates. The benefits look and are huge.

Please get in touch ( to find out how we can help you set up a well proven and efficient library development process.

Written by: Alessandro Picarelli – Engineering Director

Please get in touch if you have any questions or have got a topic in mind that you would like us to write about. You can submit your questions / topics via: Tech Blog Questions / Topic Suggestion


Got a question? Just fill in this form and send it to us and we'll get back to you shortly.


© Copyright 2010-2024 Claytex Services Ltd All Rights Reserved

Log in with your credentials

Forgot your details?