Monthly Archives: November 2014

Build Error

Continuous Integration Is Not Enough

“Do you have any experience of Continuous Integration?” seems to be a relatively common interview question in software development these days. It makes sense – checking that unit tests still pass, and that the product builds as expected with every commit to the main development line, ensures that only small amounts of effort at a time are required to maintain software quality, and that it doesn’t all need to happen in one large block after development is complete.

However, with the Release Early, Release Often philosophy, software development is moving beyond CI, and towards Continuous Delivery (ensuring every change is deployable to a production environment) or even Continuous Deployment (where every change is in fact automatically deployed to a production environment). One of the drawbacks of RERO can be that users need to update their software more often, but in web applications this doesn’t come into play. This means Continuous Delivery and Continuous Deployment are perfectly suited to web applications.

Continuous Delivery and Deployment bring several advantages. For example, developers or systems administrators spend less time building and deploying, as the process is largely automated, and it becomes easier to detect which change introduced a bug (especially ones which adversely affect performance). Additionally, features and bugfixes are released as soon as they are ready – they do not need to wait until the release window if they’re ready early, or wait until the next release cycle if they need another day. Similarly, releases are not held up due to an issue on a specific change. This means customers get features faster, and can provide feedback and be more involved in the development process.

These advantages do come at a cost, as enabling a software project to move to Continuous Delivery and Deployment can be a complicated process, depending on the state of the product. To start with, you will need a DVCS such as Git in order to separate each development or fix into a separate branch. This will also help with merging. Trying to do it on Subversion will kill you. If you’re not already using a DVCS, there’s going to be a learning curve.

Your life will also be easier if you’re using cloud computing to host your web application. It will mean that deploying a new version can be done by creating entirely new servers to deploy the application onto, instead of offlining/updating/onlining servers in sequence. The advantages here are that two versions can run concurrently, and that rolling back a release is as simple as offlining the new servers. It also means that you’re temporarily increasing capacity during a deploy, instead of temporarily decreasing it, and deploys are faster, which is essential when deploying often. Again, moving to cloud hosting may involve a learning curve.

Finally, there will be a cost involved in the setup or creation of deployment tools, as there are likely to be significant changes in process here (configuration, scripts, builds, etc.). Along with hosting, this might require a dedicated systems administrator or a move towards DevOps. Again, there is a learning curve and/or a cost to this.

With all this in mind, perhaps it is time to start asking whether candidates have an interest in, or experience of, Continuous Delivery instead.

Photo by Noah Sussman via flickr.

I love my job

The Cost Of Replacing Staff

An article in The Telegraph earlier this year caught my eye. I’ve mentioned once or twice that staff turnover, and the resulting knowledge loss, can be costly. The article in The Telegraph provides some numbers which are really quite startling:

The average fee for replacing a departing staff member is £30,614, says Oxford Economics and income protection providers Unum. This figure comprises two typical amounts – £5,433 for logistics, such as agency fees and advertising, and wages during the time when a new employee is yet to reach optimum productivity level, believed to be an average of 28 weeks at a cost of £25,182.

And specifically for IT:

IT and other technology is most affected by high staff turnover. The overall sector figure is approximately £1.9bn per year. Workers take more than seven months to reach their peak, at a cost of £31,808.

With most probationary periods lasting three to six months, this means on average a developer will reach the end of probation before reaching optimum productivity. Consider also that the average salary for a software developer in the UK is £30,000. This means the average cost of replacing a developer is higher than the cost of paying that developer’s salary for a whole year. Over the course of a year, losing one staff member a month would incur a staggering £367,368, or £381,696 in the case of losing one developer a month. Depending on the size of the company, this can be an unassumable expenditure.

According to Forbes, employees changing jobs can expect a salary increase of between 10 and 20%. Retaining the 12 departing employees, then, would cost between £36,000 and £72,000. It’s still a lot of money, but it’s only a fraction of the cost of replacing them. With such a large divide, it also allows the company to address other issues to aid in staff retention – employee benefits, training, work environment, morale, and so forth.

Photo by cobalt123 via flickr.