Hacker News Reader

Comment by heurisko | Hacker News Reader

The GDS have now become what they were setup to avoid. That is, they were supposed to be an agile startup to avoid massive overspend on untenable projects like NHS digital [1].

What I've noticed is that "new style" government projects like the GDS seem to be suffering from using too many "innovation tokens" [2], probably due to the much cited lack of leadership.

It's not nice to be in a situation where you are stuck on a legacy Java 7 platform, and nothing else, but equally, it's not nice to be in a situation where you are trying to support and context-switch between too many stacks. One is too conservative, the other is chaos.

If there's no leadership, there's no-one to make decisions to limit proliferation of new technology. This might be unpopular for some developers looking to improve their CVs, but necessary for the organisation as a whole.

[1] https://www.bbc.co.uk/news/uk-politics-28464002 [2] https://mcfunley.com/choose-boring-technology

View on HN

Having done some government contracting (and I know government contractors have a reputation for being expensive and clueless, but I know I've worked with some sharp folks) I think one of the challenges here is government's demand for a 100% solution. That sort of runs orthogonal to the typical agile/startup approach. This sounds like a project where saying "let's serve the 70% of easy users to get our foot in the door" isn't an option. This is a government service that apparently all UK residents are entitled to. That's a daunting scenario for even the most agile.

> support and context-switch between too many stacks

I don't believe this is the case at GDS, and wasn't the cause of the failure of the Gov.UK Verify project.

I don't think it was the cause of failure for the Verify project.

But I do think it is the case at the GDS, as evidenced by the comment on this page:

> GDS is full of mostly django based systems, some legacy ruby and that's just the stuff from the last few years. Going back further there are various C# systems, the amount of separate systems is staggering, it's not too surprising costs add up

And this blog post:

> ...quickly agreed that rather than try to settle on a single one of those we'd build each tool using whichever technology would most quickly get us to a relatively-durable prototype, and then "federate" them. We started with the python-based framework Django for the Department pages, added Ruby on Rails for a suite of tools focussed on specific tasks, and used Sinatra (another ruby framework) to glue together our search.

https://gds.blog.gov.uk/2011/05/12/a-brief-overview-of-techn...

Have you worked at/with GDS or is this an opinion you've arrived at from afar?

The blog post you linked to is a decade old (2011) and mentions using Django and Ruby for Rails for building a "relatively-durable prototype".

The Government Digital Service (GDS) code is on GitHub (1.5K repos) and this includes the frontend code for GOV.UK.

They still use Python and Ruby languages, but it's not clear if they are still using Django and Rail frameworks.

Other languages include Javascript, Go and Java: https://github.com/alphagov

Keep in mind that alphagov is just a small part; most projects belong to other govt departments. Many are using JavaScript and Rails, some Django and .net.

I currently work at GDS, and I don't recognise what you're describing. There are lots of problems, but Java 7 doesn't have much to do with any of them.

Reply on news.ycombinator.com