The inefficient public sector (HMRC)

(No Ratings Yet)

Loading ...

August 5, 2007 by mike

One of the biggest problems for vendors supplying the construction industry is the sheer complexity of the messaging system (this is a topic all of its own). In short, it involves connecting to, and messaging with the Government Gateway, waiting for responses, checking for errors, polling, and reading back the information, checking for errors again and continuing with the business rules. It’s complicated, let’s leave it at that.

Over the weekend, I was playing with exactly the same technology (XML and SOAP) - but this time instead of the Government Gateway server, it was the YouTube video server. I would imagine the YouTube video server to be servicing hundreds of thousands of queries per minute - far more than the Government Gateway (which crashed from demand in the opening days of new CIS). It took me two days to write an entire query engine (with base classes for videos and collections). It’s taken almost two years to get a product to market (at least six months of which was the messaging facility, including attending or receiving notes from developer meetings in Euston Tower, London) to do the same thing with a UK Government Project.

The documentation for the YouTube web service is a couple of pages long. Explanation of the classes, properties and the methods. It isn’t signed by anyone, and you don’t need to go through a long process to register with them, just give them your email will do.

The documentation for the Government Gateway service is huge. You will need to download all the Government Gateway messaging documentation, filter out the dull 1980’s EDI bits and then go and get the New CIS schemas and business rules. Printed out, on 120gsm paper (posh paper), the stack of reading (including the bits on learning the scheme) would literally kill someone if it lands on them. This documentation, going on for miles, signed off by almost everyone in the public sector, serves only to confuse and keep everyone but the most tenacious developer from understanding it.

It also doesn’t help that the way in which HM Revenue & Customs have their data designed isn’t normalised or intuitive.

To be fair: HM Revenue & Customs themselves are very helpful. They have a software developer support team who supremely helpful and are always available for geeky technical conversation. However, they cannot answer any questions on the Government Gateway or assist on the live service (did I mention there was no black box test service??). It’s not their fault, on the contrary, power to those with technical ability - put them in charge please!

So the question needs to be asked. Why does the public sector go the long way around to do something so simple? Why does it take millions of pounds of tax-payer money in the public sector to accomplish something a 15 year old script kiddie can do - before dinner - on their PC in a bedroom?

As a former consultant to the public sector, I can tell you:

Lots of people
Lots of arse-covering

Every man, woman, child and dog needs to sign off and see every specification. Everyone needs to debate every last bit of the implementation, and common standards and practices are not used, because there are so many parties involved. There is no engineer-manager at these places. With regards to HM Revenue & Customs, this is expecially true, as even when their servers blow up - they have to call in third party (very expensive) consultants to fix up their own systems.

This is why I love being in charge of my own Micro ISV.

I turn up at work, greet whoever is working with me that day (we subcontract), and put on some music and get to it. If a design decision needs to be made with a client, we call or email that client and put it to them directly. If it’s a technical decision - we get to it and get it done.

If we need to procure something. A product, a set of new controls, a new spikey office plant - we go and do it. No rubber stamps, no conferences.

I have worked myself on behalf of customers, in a shed on a lake in freezing tewkesbury for a week. I have delivered whilst on a plane. In a restaurant (god bless mobile devices). At 6am outside a train station. At 4am, chugging coffee at a neighbours house. At 3pm after landing at a small airfield in Dorset, as a passenger in a friend’s light aircraft.

As countless innovators in California have shown us; Small, agile and focussed beats big, corporate and slow - every single day.