More than I can chew

By Andrew Clifford

If your development is optimised for delivering small increments, then you had better stick to small increments.

I have just spent a very frustrating week testing a new release of software and getting it ready for production.

Usually, testing new releases is relatively painless. We have automated regression tests for every part. There are occasional problems, things that unexpectedly stop working, or tests that need amending, but generally I can get a new release through tests in about half a day.

On this release, it took me a week to complete testing and get the release into production. I have been trying to think why this release has been so much more difficult than others. I think the answer is that some of our usual disciplines had broken down.

To give some background, we are a small company, and early on we realised that if we were to compete with larger companies we would have to be smart about how we develop software. We invested a lot of time on structuring our software so that it is easy to amend, on documentation, and on building tests. This allows us to continually enhance the system in small increments. In many respects it is an agile approach, but we have arrived at it from business necessity rather than from any ideological or theoretical basis.

Larger organisations have more resources, and they do not need the same disciplines. They have resources to investigate, to amend code, and to create new tests. They can assign people permanently to different parts of the software, to ensure that each area is properly represented. They have a capability to take on much larger change projects, though their costs and speed of response are higher.

In hindsight, the mistake we made with this last release was to put too much in it. Our methods are optimised for small increments, where the impact on the software is relatively small.

In this case we were making three significant changes: a new web services interface, a revision of code for user authentication, and new methods for managing user interface themes. We had been playing around with these separately from the main body of code, and then rolled all of them together into one release.

Because these changes had been developed separately from the main body of code, there was a lot of work involved in properly reintegrating them. It is much harder to insert a fully-formed piece of code into a system and get it to work properly than it is to gradually add the functionality, carefully thinking through the implications as you go.

As well as the problem of reintegrating code that had been developed separately, we had the problems of the changes interacting with each other. For example, we had worked through the implications of the new user authentication methods reasonably well, only to find that they did not work with the new code for web services and for user themes.

Simply put, because of the size of the release, we had accidentally abandoned the agile principle of constant integration, and suffered accordingly. The moral of the tale is simple. If your development is optimised for delivering small increments quickly, then you had better stick to small increments.

Subscription