Part of the joy of working in digital policy in the UK is that many of your days start like this:
I, a Tory politician, have a brilliant plan / erudite commentary / a policy announcement on tech policy strategy. Click here to read it in this EXCLUSIVE Elite Broadsheet Newspaper piece.
We all know full well that this is how the game of politics works. These brilliant plans, erudite commentaries, and policy announcements aren’t made for you plebs. They’re made for the machine to feed the beast inside it.
The bipartisan deal contains a pot of money to repair America’s roads and bridges, and build a few more besides. This is the way we usually do infrastructure in America. First we build a ton of roads and bridges that are highly expensive to maintain, especially with our ruinously high construction costs (see this recent article by Jerusalem Demsas). Then, because costs are so high, we wait for a long time to repair the roads and bridges, until civil engineers start screeching, roads get potholed, and there’s a bridge collapse or two. Then we muster up the political will to throw the requisite shit-ton of money at the problem, the potholes and weak bridges get repaired for twice the amount it would have cost had we done it on a regular schedule and three times the amount it would cost if we were a normal rich country. And the whole cycle begins again.
Whilst Feature Parity often sounds like a reasonable proposition, we have learnt the hard way that people greatly underestimate the effort required, and thus misjudge the choice between this and the other alternatives. For example even just defining the 'as is' scope can be a huge effort, especially for legacy systems that have become core to the business.
Most legacy systems have 'bloated' over time, with many features unused by users (50% according to a 2014 Standish Group report) as new features have been added without the old ones being removed. Workarounds for past bugs and limitations have become 'must have' requirements for current business processes, with the way users work defined as much by the limitations of legacy as anything else. Rebuilding these features is not only waste it also represents a missed opportunity to build what is actually needed today. These systems were often defined 10 or 20 years ago within the constraints of previous generations of technology, it very rarely makes sense to replicate them 'as is'.