The GOV.UK Verify technical delivery team recently started building a new version of our frontend application (not the design - that will look the same as it does now). We thought we’d share how we’ve been approaching this work.
The frontend acts as the interface layer between the user and our system - specifically, it handles the creation of the web pages you see when you use GOV.UK Verify.
We decided to replace the existing frontend as we wanted a smarter way to add support for Welsh language users. This has also meant that we could pursue the development of GOV.UK Verify in the open (Kit is going to be posting shortly about our plans to do more of this).
Combining a tried and tested framework with a brand new programming approach
The new frontend is being built using Ruby on Rails. One of the main draws for using Rails is its first-class language localisation support. In addition, it’s a tried and tested platform and generally enjoyable to work in. Much of GOV.UK has also been written using Rails so it is an added benefit that we can learn from their experience.
Our aim is to introduce the new frontend to GOV.UK Verify incrementally as pages are built and tested.
So far, the team has been following a mob programming approach to the development of the frontend. To quote its founder, Woody Zuill, mob programming is "All the brilliant people working on the same thing, at the same time, in the same space, and on the same computer". The team was introduced to mob programming after Woody visited and spoke at GDS on the topic.
We’ve been doing this by forming a group of between 3-7 people that tackles one task at a time. One person will ‘drive’ the mouse and keyboard while the rest of the mob act as ‘navigators’ by suggesting what source code needs to be produced. Not everybody will be part of the mob at all times with people leaving for side tasks or other distractions as they need to.
We decided to adopt mob programming as we believed it would help establish a shared and consistent understanding of how the new frontend would be built. We also felt that by forming a mob of several members, we would significantly reduce the chance of disruption to delivery when team members aren’t available.
Lessons from mob programming
It’s still early days, but the team is optimistic and happy about this new way of working. At the end of a recent retro the following points were agreed upon:
- Knowledge transfer between team members has improved
- Communication around technical and design decisions has increased, especially with respect to whiteboarding (where the groups create a high-level design on the whiteboard)
- There is strong shared understanding of what’s being built between the members of the mob
- The mob is resilient to interruptions and unexpected absences of its members
- The mob is energised and is able to stay focused on the story at hand
As a team that already encourages pair programming the switch has not been too foreign, but there are still areas of improvement. We’re holding regular retros so that we identify these areas. We’ve found a few so far:
- We should improve how often we rotate between who drives the mouse and keyboard
- We should investigate how we can improve our development setup to support mobbing whether through better hardware or software
- We should make sure that more introverted team members don’t feel too uncomfortable to help navigate
It is not for certain that mob programming will become our default way of working for all tasks but, while we’re rebuilding an important system like our frontend, having the advantage of most of the team involved and on the same footing is beneficial. We'll start introducing the new frontend application in March.
For regular updates on GOV.UK Verify’s development, subscribe to the blog. You can also follow Chris on Twitter.