Solving `Passport Application` with Haskell

I've worked on a variety of large UK government systems for the past ten years.

This blog encapsulates the problem of writing government services/software, which often results in strange outcomes.

Writing software for government is essentially the codification of centuries worth of Acts of Parliament.

Now imagine building the HMPO passport system, and then some underlying Law/Act is changed or repealed etc.

Now someone has to find and change everything that the Law/Act affected in all systems.

Now consider that the government frequently outsources this work to expensive consultancies who are motivated to elongate contracts and extract maximum value from the client... And ideally become entrenched.

All whilst building systems of varying quality and inflexibility so that the next time that a Law/Act is changed then this whole process repeats.

There is no central decision making authority to wrangle this problem (there used to be Spend Controls), which is why Government services delivery is so expensive.

Do you have any insight as to why, seemingly, there is no contractual obligation on contractors to make a working system. They seem to make something approximating a working system, vastly overcharge -- like x1000 -- for output that appears to be 3 months of work by one junior programmer, but then get paid as if the system actually worked.

> Do you have any insight as to why, seemingly, there is no contractual obligation on contractors to make a working system.

Often, you'll find that procurement is handled by someone working off of an incomplete set of written specifications. The procurement officer probably has no expertise with or informal knowledge of the problem to identify problems in advance, and even if they do legal requirements (ironically designed to ensure fair and transparent procurement) might force them to disregard informal knowledge over the formal specifications.

After the contract is signed, sunk cost fallacies and optimism biases take over. If the project goes over budget it might be easier to cut back on features than admit failure or demand more money, and the project will go over budget once real users start seeing the in-progress work and change requests pile up. Project managers want to be seen managing a successful project; nobody's rewarded for being the first to predict failure.

This is a kind of principal/agent problem that the private sector partially manages with equity or deferred compensation, but the profit motive has a very limited role in government and you'd probably not want to give stock options anyway. Beyond that, even the political overlords have short time horizons of 'the next election', and announcing a grand new project is almost as good as delivering one.

A high-profile example of this problem is the Canadian federal payroll system (https://www.oag-bvg.gc.ca/internet/English/att__e_43045.html), which has led to billions of dollars in fix-ups over a decade or so.