Rhys Bridges

Director at AppStratum

After over 40 years of programming experience and 30 years in the software industry, having watched fads come and go with fashion, I see the same code being hand-written again and again, with much the same problems to solve and almost always the same set of defects to resolve. The Cloud and Agile do not change this.

I see organisations that have many different (and incompatible) ways of storing a postal address within their own organisation. So much so that they now believe it is impossible to safely share such data across their systems due to multiple sources of the truth being a very real problem for them.

I see generation after generation of developer, bright eyed and full of enthusiasm, believing that their latest language, framework and development tool set is the greatest ever, yet they seem to be far less productive than developers from the late 1990s.

I see the shock on even experienced developers faces when I construct a non-trivial and high-performance 3-tier business application executable, without writing a single line of code, using a schema-driven RAD/JAD tool from 1997 with drag and drop capabilities in about 3 minutes. And yet, they still want to build their next application with hand-written Scala or Java or C# because, despite being shown they're really working in the stone age, they're in love with the expressiveness of their latest application programming language and its test framework.

As one developer put it to me: "I know what you've shown us in 3 minutes would take our (Agile) team 2 to 3 months to write, but I don't like it because it's just too easy and I prefer to write my own code because I trust what I'm doing". The same developer introduced over 180 defects in the next 4 sprints of his project: 45 per sprint on average.

I know of a major income tax return web application that delivers over a quarter of a G7 country's annual government revenue, but that is virtually impossible to make substantial modifications to because the government and systems integrator in question are both terrified of the cost of change: the government financially and the SI because of risk and the potential loss of reputation. Therefore the app, one of the worst designed Java applications I've seen - that uses textbook clean separation of concerns and object-relational mapping - remains in production for the foreseeable future after 11 years of a very expensive 24x7 "mission control" operations to see it though its annual peak of database traffic. This despite the fact that on the one occasion it failed, it kept call centres busy for several months as taxpayers tried and failed to get through to the Helpdesk to complain after being fined for this applications own technical failure on one night of the year.

The same government took direct control of reimplementing its corporation tax return as part of its Digital strategy and took 4 years rather than the 8 months originally estimated to deliver the front end (a web app). The server-side services have subsequently been left relatively untouched. The Digital programme, initially seen as the instigator of healthy "disruption" is no longer chomping at the bit. Nobody wants to rock the boat anymore or have their otherwise good reputation burned.

This best-performing government department in terms of IT delivery, responsible for collecting tax and duties, took nearly 3 years and nearly 300 million dollars to deliver a simple 3 page app running in a private government cloud. The app merely collected an email address in order that tax notifications could be sent to that email address by another system. The organisation is internationally celebrated as a exemplary Digital Service and is as Agile as any public or private organisation that I know of, being far better at Agile than most. Yet its crippled by the application-centric environment in which it exists.

This government department wins awards every year for its Digital platform (a very large collection of microservices), its innovation and dedication to modernisation. Nevertheless, after over 5 years, all the signficant nontrival tax web applications run on 2008-era J2EE technology, a very expensive proprietary database and an inflexible ERP system, maintained by one of the most expensive outsourcing contracts in Europe.

This same government department has always retained an in-house IT capability. This revolves around a mainframe computer dating from the late 1960s and, I understand, remains a provider of gainful employment for COBOL programmers.

The same is true of the banks. Some of the biggest and most successful banks in the world (and I speak from experience having dealt with some of the biggest banks in one or the world's two leading financial centres) have incredibly antiquated systems. So old in fact that ASCII character encoding is too recent to be compatible with their systems. Again, they're terrified of the costs and risks of change and so stick to technology that was already appearing dated in the early 1970s. Yet the costs of maintaining these systems and the extensions to them are astronomical.

This costs all of us, be it through charges, taxes or lost opportunities. It stifles competition and innovation. And sooner or later it must come to an end. A Data-centric vision, combined with other advances and technologies is now at the point of being able to deliver a fundamental shift in the way that we think about and develop IT systems.

I am absolutely convinced that the Data-centric approach is the most sensible and pragmatic way to change the current state of affairs. I believe that advances in ML and rediscovery of programming paradigms compatible with the Data-centric approach will inevitably (and at some point quite quickly) replace the status quo.