BBC College of Technology: Develop conference videos

In November 2014 the BBC Academy hosted Develop, the BBC’s annual conference for developers.

Celebrating its fourth year, the conference was spread over two days in Salford and London, complete with an international cast of speakers and a variety of topics, ranging from ‘antifragile’ software to Twitter data visualisations.

With all of these renowned practitioners in one place we took the opportunity to film some interviews about a few of the most important current trends in software. The resulting short films have been published recently on the College of Technology website.

Monoliths and microservices

The traditional approach to building software has often relied on ‘monolithic’ applications. These are big, potentially unwieldy, single systems that can require complete redeployment when even a small part of them is changed. In the words of ThoughtWorks’ principal consultant, James Lewis, these sorts of applications "don't really talk to one another very easily, are very difficult to integrate with and are really, really hard to maintain."

In the film Lewis describes why ‘microservices’ are becoming increasingly popular. These are applications built as sets of independent, decoupled components, which can be separately deployed, separately maintained and separately scaled. Rachel Evans, principal software engineer, BBC Future Media, explains how, Video Factory, the transcoding system that powers BBC iPlayer, has been specifically designed in this way.

The need for resilience

Part of the appeal of a microservice architecture is that it can help ensure software has greater ‘resilience’. Essentially this means that any failure that might occur within a part of a system does not have a knock-on effect on the whole service. This film explores in greater detail what resilience means, how systems can fail ‘gracefully’, and why – especially now that cloud computing is so prevalent – it matters so much.

Umesh Telang, general engineering manager in BBC Platform Services, explains how the BBC are using new tools such as Chaos Monkey to actually simulate cloud-based system failures as a way of ensuring systems are as resilient as they can be. We also have a short article ("Keeping software resilient by embracing failure") which reveals this process in more detail.

Why do you need to test software?

What does a tester do? What are bugs? This article provides an introduction to the process of software testing, including a series of accompanying videos which explore different approaches.

A forthcoming article will cover the future of testing and whether the role of the tester is in danger of being made redundant by automated testing.

The big debate: is TDD dead?

For many software engineers, test-driven development, or TDD, will be all too familiar. This involves a cycle of writing an automated test that is initially designed to fail, before then writing the production code to satisfy that test. At Develop we hosted a debate on the subject of whether or not TDD has run its course as a methodology, featuring a panel of experts.

The discussion is inspired by creator of the Ruby on Rails web framework, David Heinemeier Hansson's complaint that TDD feels like an oppressively dogmatic and, at times, needlessly involved development practice. As panellist Eleanor McHugh explains: “TDD is a tactic. It’s a technique you can apply in certain situations, and one that isn’t necessarily useful for everybody.” The panel cover the aesthetics of good code, other types of tests and whether or not career progression comes into it.

Zach Holman: move fast and break nothing

Finally, we have published a lively and stimulating presentation by GitHub’s Zach Holman, entitled ‘Move fast and break nothing’. The title is inspired by a mantra for developers that Facebook’s Mark Zuckerberg coined: “Move fast and break things”. Recently a lot of emphasis in the software industry has been placed on moving ‘fast’ – trying out new ideas quickly to see if they’re viable. But if we’re moving fast, Holman asks, “what specifically is okay for us to break?” He goes on to detail some interesting approaches to this question with examples from GitHub, including parallel code paths, using ‘ChatOps’, and why it’s important to ‘own’ the code you create.