Reducing Risk through Regular Integrations

OK, I’m not quite satisfied with the example I gave (MOT) for the benefits of integrating and testing early – it was too simple.  What I’ll quickly attempt to do is convey the benefits of integrating regularly and use a little bit of maths to illustrate the cost savings.

IT projects are large engineering projects – so I’m going to take my favorite analogy of the Car.  If we have a team of developers we can imagine  each of them working separately on a each part of the project – in motor vehicle terms this would equate to developers working individually on creating a wheel, the axial, the brakes, the nuts and bolts etc.  Now the longer is it left to put the car together the larger and more complex the problems will be to solve when we find them – this is what regular integration solves.  Individually the developers may have created the best parts in the world – but when they are put together they just don’t work  (Imagine attempting to fit a tractor wheel on a F1 car).   Regular integration allows developers to find problems faster and start communicating effectively with each other earlier.

Let try and put some simple mathematics around this:

  • Number of developers on a project separately we can call this Number Developers = D
  • Time between building and Integrating = I.
  • Every time a Developer attempts to integrate with another developer routine (or part) there is a potential Risk that that integration won’t work =  D * square root D.  (Not all routines communicate with each other, so lets take the square root)

Then we can see that the integration risk factor = (D * sqr (D) )  * I

For simplicity we are going to assume that every day each developer will create a new and distinct part.

Num Of Dev’s     Risk        profollica scam Int Time = 1     Int Time = 5       Int Time = 30    
1.0 1.0 1.0 5.0 30.0
10.0 31.6 31.6 158.1 948.7
20.0 89.4 89.4 447.2 2683.3
30.0 164.3 164.3 821.6 4929.5
40.0 253.0 253.0 1264.9 7589.5
50.0 353.6 353.6 1767.8 10606.6

We can see from above  if we have 50 developers the integration risk factor goes from 353 (1 day) to 1767 (5 day between integration) to a whooping 10k after 30 days.  If we look at the graph we can see the impact – this is a very simple representation of the risk factor.  I know for a fact that the longer it is left and the more developers are involved the more exponential (raises faster) the curve will actually be .

I’ve heard of many  projects where it has been months between integrations phases and these have always overrun.  The ideal way of keeping risk down is to minimize gaps between integration phases.

Key Takeaways

  • Integrate regularly to reduce project risk
  • Regular integration finds issues faster and earlier within the project lifecycle
  • Regular integration means developers are forced to learn about each others parts – this means the built product will be much more cohesive and as a result of much better quality than it would otherwise have been
  • Regular integration gives stakeholders an opportunity to see a concrete product and feedback (we said that, but actually we meant this)

I’ve said it before and I’ll say it again – regular integration is a central pillar for QA excellence within a project.  With this in place you are empowered to do other virtuous things: overnight automated testing, empowering developers to write tests, evenly smoothing risk throughout the project, enabling more predictable deliveries that are inherently less prone to risk … the list goes on.  If you aren’t doing then ask yourself why .

Leave a Reply

Your email address will not be published. Required fields are marked *