West Midlands Fire Service has sported its own in-house software development team for almost 30 years.
No one working in the team today really knows how or why “Sys Dev” came to be. Perhaps we’re the result of some long-abandoned social experiment – but no matter. From those formative days sprang something that’s still rare today: a small software development team that’s employed by a Local Government organisation.
- Three decades on, the team finds itself back in the rudest of health and, it would seem, surfing the zeitgeist like a boss. Our third-generation software framework has just hit beta and it’s looking like our best work yet.
This time round we’ve built-in-the-open, embraced CI, TDD, MVP, PWA and flexed a core Agile team of seven developers with as many SMEs. The upshot of all this industry is a declarative platform for delivering our digital services – we’ve called it Tymly (i.e. “timely”).
What follows are some personal reflections about building software in today’s Local Government.
Straight to it then…
- “The public sector can never pay people as much as their private sector counterparts!”
- “That means the public sector can’t ever hope to attract and retain decent dev talent!”
- “And that means anyone making software in the public sector must be lazy, inferior or delusional!”
Welcome then, to “Taint” – a term coined here a few years ago for describing the anxiety developers can experience that their CV (and by extension their career) will sour if they develop software in Local Government for “too long”.
Is Taint real though?
On average, we have relatively low churn (the phrase “in for two [years], in for ten” was imparted to me when I joined the team 18 years ago and it’s since proven pretty accurate). Those who do leave progress easily into more senior roles (in both the private and public sectors). Empirically, Taint seems to be a myth.
But Taint does lead to an interesting discussion about stereotypes. Do people instinctively think developers in Local Government are less talented than their counterparts in the private sector? Do Local Government developers revel in some sort of persecution complex? Does anyone even care?
We’re of course not well-placed to answer these questions objectively. In our experience though, incredibly dedicated and technically astute IT teams always exist in organisations like ours. Perhaps it’s subdued on Taint, but surely the last of the sleeping IT giants will mobilise out here, in Local Government Land? #FixThePlumbing
“In the red corner! We have the plucky upstart ‘Open Source’!”
A vision of hundreds of small agile teams spread throughout Local Government that are perfectly aligned with their product owners, contributing to open source projects alongside their peers and tapping into a rich ecosystem of SMEs on the Digital Marketplace as they relentlessly iterate.
“And in the blue corner! We have the sombre authority that is ‘Commissioning’!”
Around these parts, we understand “commissioning” to be the challenge bestowed on Local Government organisations to seize on any income-generation potential. The idea being that this additional revenue will supplement beleaguered budgets and ultimately deliver better VFM to the taxpayer.
Our team can find itself nestled horribly between these two worthy specimens. Building useful, modern software can be a lucrative business, so we’re told. How then, to reconcile this sought-after income (our HQ is in one of the most deprived wards in the UK) with a strong, publicly-spirited open source ethos? We’re fortunate to have a supportive organisation around us, but pressure on the brigade’s budget never seems to abate. Without some sort of practical support to turn to, it feels like there’ll never be any easy answers here.
Of course, there are well-proven open source business models to try. We’ve made some inroads on this front – we currently supply our services to three other brigades. Introducing paid-for services around our products (with the very best of intentions) has proved to be an incredibly challenging frontier for all concerned. We’ve regrettably failed to retain collaborative arrangements with two other brigades – we’ve enough hard-learned lessons to fill a whole other blog.
We were once asked, quite pointedly, “What are you? A Fire Service or a software house?” and that rather cuts through it all. For me, I undoubtedly work for a Fire Service (it says it on my pass and everything).
The team here live and breathe Fire Service. We’re incredibly proud to contribute, with immediacy and agency, to an amazing organisation (have a watch of “Into the Fire” on Dave if you get the chance). Be it in IT, or any other Local Government department, pride in public service is a potent and pervasive force. We see organisational pride move an army to go above-and-beyond and continually deliver more-for-less. Proponents of wholesale outsourcing of IT teams must have some clever spreadsheets to take all of that into account.
With no bonus lever to pull, healthy reserves of organisational pride are important for when things get tough too.
Our Kanban board is a powerful magnet for stories that cover a wide range of vital frontline services. Things like Agile and ITIL help, but clear prioritisation is a particularly gnarly issue when everything is so worthwhile, justifiable and immediate. There’s also an interesting dynamic at play when a dev team, their “customers” and product owners all bump around in the same line-management hierarchy. We’ve no shortage of inertia-sapping legacy systems to migrate and that’s alongside trying to deliver a justifiable ROI for those three other brigades.
No pressure, no diamonds?
As a result, our team (and indeed the wider ICT department) has undergone something of a renaissance over the last twelve months:
- Management restructures
- A concerted effort to be more outwardly facing
- The beginnings of devOps
- An Agile reboot (we use a published industry mentor now)
- A greenfield tech-stack
- Inspiring graduate stories
- Contributions from eight SMEs (and counting)
- Cloud service integrations (to complement a wider O365 transition)
- Authentication-as-a-Service (thanks to the brilliant support given to us by Auth0)
- A VDI rollout
- External code/architecture/security reviews
- Brand new roles for:
- Digital Transformation
- Business Analysis
- Account Management
…it’s been a busy year!
Emerging from this chrysalis is Tymly – our third-generation “low code platform” and SaaS. We’ve a relatively small amount of technical debt to settle, but the Tymly codebase is already lean and satisfyingly pliable.
Tymly enables an organisation to describe each of their digital services using an open vocabulary. We call these definitions “blueprints”. We’ve already written blueprints for Fire Safety, gazetteer management, fire/ambulance liaison, home safety checks and a few more.
We’ve also built companion blueprints for Open Data products such as Indices of Multiple Deprivation and the Food Standards Agency (which in-turn help inform our Fire Safety inspection schedules). We’ve written blueprints to extract, transform and load Ordnance Survey’s amazing Addressbase products too.
The blueprint concept has been designed from the ground-up to help us (and anyone else, of course) meet a growing demand for interoperability, collaboration and transparency. Blueprints are proving themselves effective around GDPR as well. We’ve found great benefit in adhering to open standards: they power everything in Tymly from defining UI content to running workflows.
It’s still early doors, but creating a blueprint is (dare it be said?) painless. That’s without a drag-and-drop editor that’s headed for a design session soon. If all goes to plan, we’ll have empowered colleagues with “non-traditional development backgrounds” to share and evolve their own blueprints by Christmas.
We’ve already had pull requests from private companies in the USA who are using our NPM packages and had contributions from DWP and GDS. We’ve built a modern and modular stack with decent test coverage and a Docker-based deployment pipeline (featuring several bots that continually help us keep things shipshape).
- As an aside, The work GDS (especially the output of @edent and @annashipman) has done in championing open source and open standards has helped keep Tymly relevant and the opportunity to present recently was very much appreciated.
It’s been great to be part of the team as it developed Tymly into something special over the last nine months. We’ve still to take it out onto the track to see what it can really do in production as SaaS.
In our more wistful moments, we do sometimes wonder if the innovative things built here at West Midlands Fire Service are a product of our alternative upbringing. We haven’t the headcount to support lots of individual systems, so do our circumstances cultivate holistic, low-code thinking?
Could the core ideas that have helped propel Tymly and its predecessors over three decades have ever come about in private industry?
Is Local Government a primordial soup of latent dev talent that will eventually coalesce into a wondrous open source ecosystem? Or is this all destined to be a glorious failure?
In publishing this blog will a commercial behemoth with a slick sales team now clone Tymly and put us all out of a job within a matter of days? Or, given recent dips in share prices, are we perhaps on the cusp of a new symbiotic public/private SME era?
Who really knows? It’s probably best not to overthink these things.
If nothing else then, hopefully our tale will help shine a light on the work of Local Government dev teams. We do and can exist. Given a bit of support, perhaps we can even thrive.
Teams like ours can feel lonely and under-supported walking this path (perhaps those feelings are further magnified when walking outside the M25?)
Minor tribulations aside, in-house development is a massively rewarding endeavour to pursue and it can easily deliver real business worth for Local Government organisations. We utterly recommend teams get stuck into some open source code and get their commits on. Contributions are always warmly welcomed at the WMFS org BTW !
Tellingly, given the chance, we probably wouldn’t change much at all about our last thirty years.