Government urged to break out of ‘technology monoculture’

The government needs to ensure it uses a range of technologies or risk putting off developers and repeating digital transformation mistakes of the past, a Ministry of Justice technical architect has said.

Departments have been told to encourage devs to experiment to tackle recruitment problems – Photo credit: Pixabay

Al Davidson said that because the choice of technical languages and frameworks can have long-lasting consequences for products, government departments end up choosing the “safe option”.

However, this means they can get locked into one type of technology, which becomes self-reinforcing over time: teams are more likely to choose a certain technology because there is a larger pool of developers for that in-house.


Related content

Running your digital project- tips from MOJ Digital
Government Digital Service calls in “hackers” to test its platform
GDS needs to focus on digital transformation – not unproven technologies
Smart working and modern workplaces: a Microsoft webinar


Although Davidson said this has some advantages, for instance hiring is simpler because there is only one skill to look for and people can switch teams more easily, he added that there are also drawbacks to this approach.

“Over time, this can lead to stagnation and issues with staff retention and recruitment,” he wrote on the MoJ’s digital blog.

“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,” he said.

“Ultimately the digital transformation of government will have merely replicated the mistakes of the past with a later generation of technology.”

Instead, Davidson urged government departments to move with the times.

“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,” he said.

For instance, he noted that the “default option” for his department, Ruby on Rails, was new and exciting in 2007, but is now seen as a “safe, standard choice”, with many experienced developers moving on to other languages.

If government wants to avoid slipping into a technology monoculture that will drive away developers and make it harder to recruit new ones, departments should make sure they allow developers to try new technologies.

“A culture that supports experimentation and learning makes for a much more attractive place to work,” Davidson wrote. “It can be a strong recruitment and retention tool in a competitive marketplace of high demand for talent, but short supply.”

However, Davidson acknowledged that there was a need for government to balance this need to encourage experimentation with safeguards against the adoption of a range of inappropriate technologies – which can itself lead to a dependence on particular staff.

“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,” he said, adding that individual teams should decide what level of experimentation is appropriate for them.

But, Davidson said, all teams should strive to create an environment that encourages technology diversity, from both the bottom up and the top down.

For instance, developers should investigate technologies outside their specialties, “resurrect” lunchtime code clubs and support others by advocating experiments with service managers.

Meanwhile, senior management should establish tech learning days, work to build a consensus among service managers that tech experimentation is in the departments’ long-term interest and recognise those who introduce new technologies.

Davidson also said that managers should introduce and regularly update its own Tech Radar system to make it clear what technologies are being considered and what are being cautioned against.

Rebecca.Hill

Learn More →

Leave a Reply

Your email address will not be published. Required fields are marked *

Processing...
Thank you! Your subscription has been confirmed. You'll hear from us soon.
Subscribe to our newsletter
ErrorHere