Skip to content

Software Release Triangles

Triangles.  Consultants love triangles.  I am moving into that line of work, I better get some practice.  Lovely things triangles.  Look pretty in presentations. 

Most people in the software industry will be familiar the Time-Quality-Scope triangle.  I am sure you know the idea – if you fix two of these variables, be prepared to compromise on the third.

I’ve invented a triangle!  Mine is a release size – frequency – code architecture triangle.  Not as snappy as the above so need to print any t-shirts yet.  But a similar concept: fix two and you will probably need to compromise on the third.  Let’s see some examples.

Example 1

Let’s fix our release frequency and release size.  We want to get new features out to our customers every two weeks.  We know how dangerous big releases are, so we want to keep the changes in each piece of our software to a nice small size.

We may be lucky and this may all work out.  But over time, we might have to consider breaking our software into smaller pieces such that the amount of change in any given piece are limited.  Particularly if the number of people working on our product is growing.

Example 2

Now let’s fix our code architecture and release frequency.  We still want to get new features out to our customers frequently.  We have no appetite to refactor or address technical debt – if we have any.  Therefore the code architecture stays as it is.

In order to keep up and avoid a huge backlog of unreleased goodness, we need to sweep up every commit generated in each cycle.  There is little you we can do about release size, we have to take what we are given.  This may be fine, but again if we are scaling up, this may get out of hand.

Example 3

Finally, let’s fix the code architecture again and fix release size perhaps for similar reasons to the above.  We need to monitor the backlog of commits, and when they reach a certain point or depth, we need to release a new version.  Who knows how quickly (or not) that backlog will grow.  Thus, if we obey these rules release timing is out of our hands.

In summary ….

Not everything may be subject to rules as hard and as fast as written here.  In the last example, maybe releasing updates is the easiest thing in the world.  In which case, we can release every commit in a new version of our software if we wanted to.  

However, the three items are related and the relationship needs careful thought at times of change and scaling of a programme.

Be First to Comment

Leave a Reply

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