Digital Transformation at Uk.Gov

This week I attended the “Digital Transformation” event hosted by Dare and it did not disappoint. Leading off was Russell Davies – Head of Creative Strategy for the UK Government Digital Services initiative and a proponent of “Usability trumps Persuasion” paradigm in digital service platforms. In his own inimitable style with a dramatic opening to the 20^th Century Fox sound track, he described the process they had gone through at uk.gov to transform the experience for the citizen.

According to Russell, Digital Transformation is about "

making services better for everyone, not just people who use the website”

The strategic vision for the GDS programme can be summarised as:

The estimated economic impact of this vision, driving the Citizen towards self-discovery and self-service has been about 60 millions pounds of annual savings.

The process of digital transformation started with pulling together multi-disciplinary teams to map all the hundreds of services and microsites and identify essential services and weeding out stuff that wasn’t needed.  The transformation delivery paradigm was built around following key themes:

1	Understand user needs. Research to develop a deep knowledge of who the service users are and what that means for digital and assisted digital service design.
2	Put in place a sustainable multidisciplinary team that can design, build and operate the service, led by a suitably skilled and senior service manager with decision-making responsibility.
3	Analyse the prototype service’s success, and translate user feedback into features and tasks for the next phase of development.
4	Consistent User experience:  use a common design framework to ensure a intuitive, responsive experience which
5	No link left behind. Use tools to re-wire the service to the new platform without fan-fare so that the users do not notice.

Incremental Service Delivery

The platform delivery lifecycle was agile, user-centred and multidisciplinary teams distributed across several sites, delivering digital services in an incremental seamless manner.

Discovery: A short phase, in which you start researching the needs of your service’s users, find out what you should be measuring, and explore technological or policy-related constraints.

Alpha: A short phase in which you prototype solutions for your users needs. You’ll be testing with a small group of users or stakeholders, and getting early feedback about the design of the service.

Beta: You’re developing against the demands of a live environment, understanding how to build and scale while meeting user needs. You’ll also be releasing a version to test in public.

Live: The work doesn’t stop once your service is live. You’ll be iteratively improving your service, reacting to new needs and demands, and meeting targets set during its development.

Retirement: Even the best services may eventually reach retirement. That should be treated with the same care as went into the building and maintaining of that service.

One of the more controversial but immensely sensible thoughts Russell left us with was:

“ Don’t innovate, first get the basics right!”

We don’t know anything about programming!

Moore’s Law has hit a limit with processing power on single processor peaking and computing systems shipping with multiple cores. Functional programming is the hot new topic in industries dealing with massive scale in date or internet scale loads. Functional programming is better suited to handling side effects of concurrency and distributed computing when compared to Imperative programming models. The lack of adequate supports on the tools programming particularly in debugging and testing have slowed the advance of functional programming and its widely anticipated growth. However, I find that the bigger challenge is the developers struggling to come to grips with the functional programming paradigms. Most programs written in functional languages (at least initially) seem to be clones of their Imperative cousins. Perhaps the fault lies in the indoctrination of the programming community about a particular way of programming (in this case Imperative) as the Universal truth. I came across this great video about the Future of Programming by Bret Victor. 

In his inimitable style he introduces hot paradigms today i.e. Dynamic Programming, Functional Programming (Can Programming Be Liberated from the von Neumann Style), Actor Model (embodied in Erlang, Akka), Massively Parallel Programming Array (FPGA). It does open your eyes to how many of these ‘hot’ paradigms have been around for so long. But the most compelling part of the talk was the last bit where he advocates keeping an open mind [1]“It's good to learn how to do something. It's better to learn many ways of doing something. But it's best to learn all these ways as suggestions or hints, not truth.” [2] “Learn tools, and use tools, but don't accept tools. Always distrust them; always be alert for alternative ways of thinking.” [3]“I don't know how to make a machine that builds a person out of a cell. But I think the problem is that we've been stuck for too long diddling with our details. We've been sitting here worrying about our type system, when we should be worrying about how to get flexible machines and flexible programming.”

Like Bret says – ‘do not be ignorant, but we need to be aware of the limitations and strengths of different programming paradigms, and be willing to explore flexible approaches to programming and not get stuck too long diddling with the details’

Parallelism from ‘Scratch’ 

A year ago, my son aged 8 started showing an interest in programming after we installed a desktop in his bedroom. He loves the Scratch Programing tools, a fabulous Interactive Programming Environment from MIT Labs (remember Grail from Bret’s talk) create stories, games, and animations. Condescendingly, I decided to teach him the ‘right way’ to learn programming. Normally when you are teaching programmers, they are happy if their programs can display some web pages and interact with a data store, but to say that children are demanding would be a massive understatement, They want their characters to fight dragons, morph into aliens, scream, jump, jump, spin, get new weapons, and have multiple lives… It is a chaotic ‘Omniverse’ which would stress the best of programmers. It was amazing to see him use concepts from parallel programming coordinating game characters using messages without the concept of shared state or threading to manage concurrency. It just reinforces Bret Victor’s advocacy of free thinking – children are not limited by particular paradigms and aided by the right (visual and interactive) tools can surprise you with the complexity of their programs. Imagine creating some of these games (which are so simple for a kid to ideate, create and program) in a mainstream programming environment.

His First Program