This is the first in a series of technical blogposts we would like your feedback on. Let us know what you think and what you’d like to hear more about.
When building a team to produce software, the choice of language and/or framework used can have significant consequences throughout the lifetime of the software. As a result, people tend to choose the ‘safe’ option. Long established technologies with large pools of available developers within the existing team.
Here, Ruby on Rails has become the ‘default’ choice for new products. Python use is dwindling. This tendency towards a technology monoculture becomes self-reinforcing over time. Teams are more likely to choose Rails due to the larger pool of in-house Rails developers.
There are some advantages to having a single dominant technology - hiring is simpler as there is only one skill to look for. It’s also easier for people to switch teams. There are also drawbacks which should be addressed. Over time, this can lead to stagnation and issues with staff retention & recruitment.
This has not been a problem to date as in Government terms, Ruby on Rails is still considered ‘new’. But if it is left unaddressed, we will face an increasing number of issues in future.
Developers will move on to learn new skills elsewhere. Hiring developers to work in a less exciting technology will become more and more difficult. The existing applications will become harder to support, turning into accumulated technical debt.
Ultimately the digital transformation of government will have merely replicated the mistakes of the past with a later generation of technology.
Technological diversity helps hiring and staff retention
In 2007 Ruby on Rails was an exciting, new technology that many developers wanted to learn. In 2016 it is seen as a safe, standard choice, with many of the more experienced Ruby developers now moving on to other languages.
In future, like any other technology, it will decline compared to newer options. Hiring developers to work in it will become more and more difficult.
Developers want to keep their skills up to date and learn new technologies. If they are not allowed and encouraged to learn and experiment, many will eventually leave. When trying to attract new developers into the team, a technology monoculture is only as attractive a place to work as that technology is in the marketplace.
All technologies undergo a process of emergence, adoption, stagnation and deprecation. The further along that process a technology is, the more difficult it is to hire developers to work in it.
A culture that supports experimentation and learning makes for a much more attractive place to work. It can be a strong recruitment and retention tool in a competitive marketplace of high demand for talent, but short supply.
Guard against over-experimentation
A competing pressure is the need to support and maintain any new applications over the course of their lifetime - usually of the order of 2-5 yrs. Over-experimentation can result in an over-abundance of inappropriate technologies in production. This can lead to critical dependencies on particular staff and subsequent support issues (‘I have a Go app with an urgent problem and our only Go dev is on holiday!’)
A suitable balance must be found. Supporting learning and avoiding stagnation on the one hand versus the need to avoid single points of failure and continually improve your software on the other.
Each service area and each product team will have their own constraints and pressures. The logical place for decisions about technology experiments is within the team itself. Experiments should only be conducted with the full agreement of the developers’ product team.
Encourage technological diversity
A successful technological diversity drive will rely on being able to find a happy medium between competing pressures. It needs to be driven both from the bottom up, and top down. The following are suggestions for how we could improve our diversity:
From the bottom, up
- Through the developer community, encourage devs to read up and investigate technologies outside their main speciality
- Resurrect lunchtime code club and Tech Time talks about new technologies and techniques
- Build a culture of experimentation and learning as well as delivery
- Encourage devs to set objectives which include learning a new technology
- Support devs in advocating tech experiments with their service managers
- Share knowledge and encourage “What we learned” debriefs at Tech Time, Show The Thing, etc
From the top, down
- Re-introduce periodic no-backlog days, but explicitly re-brand them as tech learning days
- Introduce Tech Radar to make explicit what new technologies and techniques we are considering, trialling, advocating, and cautioning against
- Update periodically - say, every 3 months - collaboratively, with all tech staff
- Publicise updates on the blog, and internally across the dept & wider government
- Build consensus amongst service managers that technological experimentation is in our medium and long-term interest
- Support developers who want to learn - accept a short-term impact on the first delivery in a new technology for longer-term gain
- Recognise and praise those who introduce successful new technologies & ideas
In the next post, we'll share our thoughts on how to evaluate new technologies, and how to make technical experiments less risky.
2 comments
Comment by Owen posted on
I realise the invitation to comment is a little stale now, but FWIW I'm very interested to read about the decisions being made in government around the technical platforms digital services are being built with. Personally I'm surprised that Python use is waning though: given the importance that I'd have thought data would have to the design and delivery of your services, Python seems like a natural language to work in with a mature selection of libraries that make ML, NLP and analytics pretty easy to implement.
Comment by Al Davidson posted on
Hi Owen, thanks for your comment. To be clear - that statement refers just to web-based digital services, like https://www.gov.uk/prison-visits. We do have a large team of analysts who use several languages including python and R for their data science work, but that work is decoupled from the direct dev work on digital services, and not included in the "default choice for new products" line.