Following on from last week's post on the editorial development of BBC Taster since launch, Connected Studio's Principal Software Engineer Chris Northwood gives an insight into the technical development of the innovation site for new ideas.
Six months ago we launched the online home for new ideas from the BBC: BBC Taster. In February, Eleni Sharp wrote about how we went about building the site, taking it from a prototype into a robust audience-facing product.
Innovation at Scale is at the heart of Connected Studio’s mission, and to be able to respond to change rapidly allows the BBC Taster team to this innovation, rather than get in the way of it. I’m the Principal Software Engineer on Taster and I’m going to walk through in a bit of technical depth what we’ve done in the past six months to keep BBC Taster lean and rapid to change, and avoiding it turning into a big ball of mud.
At the core of this has been the application of Continuous Delivery principles, which we learnt from the BBC’s continuous delivery pilot. I’ve previously blogged about how the iWonder team applied Continuous Delivery principles, and we applied those same high-level principles to BBC Taster.
At the core of Taster has been the application of Continuous Delivery principles
In the run up to launch, the team were working at a greater than sustainable pace to get the minimum viable product of BBC Taster out there. This led to some engineering trade-offs, but we agreed to do this on the understanding to have some “technical debt time” immediately after launch. At the first release, BBC Taster was a single application written with Ruby-on-Rails. Ruby-on-Rails is a great framework for rapid application development, however it is also constraining to working in the “Rails way”. If you want to do something outside of this scope, Rails becomes painful.
To pre-empt this, we decided to take our Rails app and break it apart, moving to a microservices architecture, leaving the Rails app simply serving up our HTML, and with all the heavy lifting done by brand-new components written in Node.JS. The journey wasn’t as smooth as we would have liked, but utilising techniques such as GitHub flow with continuous integration (so no branch lasted longer than a few days), as well as moving our build tooling from using Jenkins to Go.CD with full automation at all stages. We also increased (and continue to do so) our level of end-to-end test coverage, adapting the PUMA principle, but instead of using Cucumber, we simply implemented the tests in RSpec, leaving our “Amigos” happy to specify the acceptance criteria in a more natural form than the somewhat constrained Given-When-Then language.
Applying the continuous delivery principles for delivery of BBC Taster, as well as re-architecting our application to use microservices, ing to refactor when needed and applying good code cleanliness techniques (especially the “boy scout” rule) has helped us stay lean and able to respond to change quickly, and allow BBC Taster to be a platform that enables us to try out new ideas and fail fast.
Taster enables us to try out new ideas and fail fast
These improvements do not simply improve the life of the technical team, but of the wider team as a whole. As a result we are now able to work more closely with the UX and Product people in our team to respond much more quickly to the information our analytics give us, as well as allowing us to be more ambitious with what we can promise to our stakeholders.
In the coming months on Taster we’re planning on using A/B and multivariate testing extensively to help steer the direction of the site, as well as using these experiences in building out the Taster platform to advise pilots planning to become available on the page, to help get the most we can out of the new ideas we’re launching onto the site.
