We’ve been talking a lot in GOV.UK about our need to deliver responsibly through our 2017 to 2018 roadmap. We’re having 4 x 11 week mission periods and we want to ensure that while we deliver at pace, we don’t do this at any cost.
I’m very keen that a byproduct of how we’ve structured the roadmap means we find the right balance between shipping things and avoiding both people and technical debt. Or rather, we don't want such an incredible year of shipping new and improved things that it leaves our team exhausted and the platform in such a state that we need to spend the following year paying down technical debt again, before we can make further progress.
Finding this balance is not unique to GOV.UK – many organisations are working on finding this balance.
The idea behind this blog post was to collect multiple perspectives from a number of people in GOV.UK on what they understand responsible building to be.
Paul Bowsher, Lead Developer
I saw this tweet from Branden Faulls (@omphe) recently:
“If I wrote my Hippocratic oath for my work in Ops, it would be, "Cope with and manage complexity, but create no more without benefit."
Which sounds really good.
To me, responsible software development means being conscious of the trade-offs we make along the way. It's fine to introduce technical debt when building services, so long as it's a strategic decision.
The most important thing is delivering a service to users as soon as possible. The debt that builds up as a side effect of rapid delivery must be paid back eventually. If we don't pay it back, it slows down future delivery. Any responsible product team has to manage technical debt in parallel with a product roadmap. This is the only way to maintain the pace of delivery and quality of service, which is what matters to users.
Sam Dub, Associate Product Manager
Responsible building means taking the time to make sure that everything a team ships can be trusted by users and built upon in the future.
It requires you to make clear the purpose and function of what you’re building – how and why a thing was created, and what it can and can’t do.
It means using agreed standards for research, design and development, and minimising the specialist knowledge needed to work on a project.
It’s part of building services users can rely on, and that we can continue to improve.
Neil Williams, Head of GOV.UK
Responsible building means:
- only building things we know we will have the capacity and capability to support and iterate continually after, and investing time and thought into minimising the maintenance overhead for those who inherit what we build
- only building things which take us towards the long term vision for the platform and its technical architecture (but experiments that help us learn count too)
- building things we can either demonstrate with evidence are improvements or roll back if they prove detrimental – this means identifying clear hypotheses and establishing how to measure them before building anything else
Alan Wright, Lead Delivery Manager for GOV.UK
Responsible builders consider the needs of future colleagues who will maintain and improve their products in years to come. They build quality in from the start so that maintenance is easier, create common solutions where the need exists elsewhere so that value can be shared, reuse the work of others where practical so there is less to maintain, and document key decisions so it's easier to figure out how and why things work the way they do.
Responsible builders only build things that add real value for users. They measure the value they expect to see, and if their solution doesn't work as expected then it is edited or deleted. It's not just about building and rebuilding: it's also about deciding not to build or to remove things that just don't work.
Hong Nguyen, Associate Delivery Manager
It is about reviewing and scrutinising the value of every story in the product backlog regularly. Deciding to do less or not build something at all will be a healthy sign that we’ve done that. It’s also about being more conscious of making it easy for other product teams to iterate and improve what we’ve completed.
Liz Lutgendorff, Senior Programme Analyst
Responsible building to me means that you don’t just build a new shiny thing, but you also leave everything around you a little better than before you arrived – for example your codebase, your documentation or the skills on your team. It also means that you can build something new and beneficial while making sure those things that aren’t getting a makeover are still supported.
But it also means doing the hard thing or the thing that you don’t quite know the edges of yet. Responsible doesn’t necessarily have to mean mundane or safe. The platforms and applications you’ve built will have to change to remain reliable and useful for your users. Responsibility comes from using data and evidence to support and challenge your team when they want to change direction or try new things.
Ruben Arakelyan, Tech Lead
Software development has the concept of the "iron triangle" of resources, time and scope. You get to choose 2 of the 3 each time you start a new project. For me, responsible building means always choosing time and scope over resources.
Firstly, your project should have a small, fixed scope.
Secondly, it should have a fixed schedule that matches this scope. This will allow the developers to plan for both building the software in a maintainable manner with little technical debt, and also documenting what they've done for the benefit of people working on it in the future.
Both a constantly changing scope and an open-ended schedule inevitably lead to an incoherent product with no overall plan or execution. Such products are very difficult to maintain or understand and are prone to breaking – the opposite of responsible building.
Tom Natt, Lead Developer
For me, building responsibly means thinking about the future by making careful and sometimes difficult decisions in the present. What we build today should be simple and documented, because tomorrow we are going to need to understand it. What we build today should be designed well, because tomorrow we are going to need to add features. What we build today should be well tested, because tomorrow we are going to need to modify it with confidence.
It also applies to our working practices. Are we pushing ourselves to the point of future burnout? Are we building too much, beyond what we can maintain? Are we showing respect for ourselves and those who come after us? Ultimately, are we proud to invite new people into our working environment?
Paul Hayes, Developer
Responsible building is building what users need in a way that is maintainable, reusable and incremental. Changes are released often and their effects are measured. Failures are learnt from and successes built upon. Building responsibly means demonstrating improvements to the things users need most.
Tatiana Stantonian, Developer
To me, responsible building means balancing user impact with long term maintainability when prioritising changes to a project. Delivering features and improvements that meet user needs is essential, and making sure we use our resources to that effect is part of responsible building. But taking a step back and ensuring that our system is robust and easy to modify in the long term is equally important. As changes accumulate, we may need to redesign the system to avoid technical debt, for instance by extracting common functionalities, which means we'll only need to maintain and modify that functionality in one place.
Tim Blair, Lead Technical Architect
Responsible building has three parts: product, platform, and people. You can’t “choose two” – all three are equally important, and neglecting any one will have a negative impact on the others.
Product is about feature control. Addition of new features should be strictly controlled: validate there’s a genuine user need, and build general cases of special snowflakes. Review features you’ve already built and remove those no longer needed or used. More features equals more maintenance and support.
Make the platform easy to work with, so people can focus on the product. Be proactive in paying down technical debt. Ensure that everything has some form of documentation: aim to increase the bus factor. Automate any regular processes such as monitoring, alerting, and deployment.
You can work around bad states with product and platform, but without people you can’t do anything. People need to be engaged in the work they’re doing, and given the agency to control that work. Everyone works in a different way, so being flexible and supportive for differing working habits is really important, and everyone needs the time to step away from work to relax and recharge at the end of each day.
These are just some of the perspectives from people in the GOV.UK team, and it’s something we’re encouraging everyone to have an opinion on.
We learnt in the first phase of our new roadmap that, amongst other things, we needed to manage mission scope better, and provide more support. This doesn’t just mean responding to requests from our colleagues in government and from the public, but also looking at the technical state of the applications and products we own and making sure they don’t accidentally fall into a legacy state. This includes documenting the decisions we make so it’s easier for the next team to understand both how things work and why they’re the way they are.
By testing an assumption that some applications were critically dependent on the knowledge of a small number of GOV.UK people, we structured our teams this year so that applications follow product managers through the year - rather than following whole teams. That means that product managers see the impact of the decisions they take over the long term, and evolving teams have to learn about new applications as they move - eroding critical silos of knowledge. Teams therefore have to build in space for learning new things, and also experience the impact of good (and sometimes not so good!) documentation to learn from, which should inform how they then do it themselves.
We know the balance is going to be hard to find. We will be monitoring metrics that tell us about our product success (does it do what users need it to do?), technical reliability and performance, and team health. If those metrics are ‘good’ or ‘improving’, that begins to give us the confidence that we’re finding the sustainable pace of development when operating a live service.
Jennifer Allum is GOV.UK's Lead Product Manager. You can follow Jen on Twitter.
