Let’s look to the UK for healthcare

The UK has government run health care. That’s been working out well hasn’t it?

Oh! Maybe not:

A plan to create the world’s largest single civilian computer system linking all parts of the National Health Service is to be abandoned by the Government after running up billions of pounds in bills. Ministers are expected to announce next month that they are scrapping a central part of the much-delayed and hugely controversial 10-year National Programme for IT.

“The department has been unable to demonstrate what benefits have been delivered from the £2.7bn spent on the project so far,” Margaret Hodge, chair of the PAC, said. “It should now urgently review whether it is worth continuing with the remaining elements of the care-records system. The £4.3bn which the department expects to spend might be better used to buy systems that are proven to work, that are good value for money and which deliver demonstrable benefits to the NHS.” A further £4.4bn was expected to be spent on other areas of the vast IT project.

H/T to Adam Baldwin.

What I don’t think most people realize is that software doesn’t scale in a linear fashion from small projects to large. I can write, debug, a deliver a program to you that prints out, “Hello world!” in a minute or two. I can easily do it in five lines of code. That figures out to about 1200 lines per day* if I were to spend the entire day coding at that rate.

Yet when you look at the number of lines of code delivered on real projects it’s about 10 lines per day per developer. On a project as large as an operating system like Windows it’s much lower.

The problem is that planning, complexity, documentation, testing effort, and difficulty goes up much faster than the number of lines of code increase. You can pump out the code at a fast rate but it’s not something that is going to work well. It will be very fragile. You can find test cases where it will work correctly but as soon as you do something a little unusual or the system is under load and the timing on something changes you can end up extremely difficult to find bugs.

As the size of the project goes up communication between teams become a problem. With a poor design a small change in one part of the system affects many other parts. Communicating and coordinating this occupies increasing amounts of time and care. A change occurred “somewhere” in the system and your code stopped working. It can take an hour or a week to find the problem and get it fixed so you can continue to add features. Even worse are “build breaks”. This is when someone changed something and you can’t even build the software into something that runs so it can be tested. This can mean every single programmer on the entire project is at a standstill. As you might imagine these are very high priority events and you can have people baying for your blood. People take them very seriously and the consequences are high but they still happen.

A former roommate working on Windows NT back in about ‘99 told me she had a bug fix ready for check-in but wasn’t allowed to for months because of concerns that it was a change that could affect other people.

How many lines of code are in the Obamacare system? I don’t know for certain but there are reports that it contains 500 million lines needs to have 5 million lines rewritten. Do the arithmetic to arrive at your estimate of how many people working for how many days is required before it will be “fixed”. My best guess is that the politicians had the U.K. model in mind and that’s what they will get (see above).

Everything I see about the Obamacare web site indicates it was thrown together by someone who didn’t know what they were doing. There are very few companies that have been able to write very large complex systems successfully. Microsoft and Google come to mind. The contractor for Obamacare isn’t on anyone’s list of successfully large scale system developers.

They claim it will be working by the end of November? Did they say which November?

* Yes. Lines of code per day is a poor way of measuring productivity. For example one can be very productive while reducing the number of lines of code in a program. Yet, it is good enough for many uses and can illustrate valid points with serious error.


7 thoughts on “Let’s look to the UK for healthcare

  1. My college aged kid worked at Jet Propulsion Labs as an intern last year and experienced their engineering software, from the same company that recently did the new electronic medical records software for my spouse’s medical practice.

    When they compared notes, it seemed the problems with one software carried over to the other software. In other words, they made garbage once and keep reconfiguring it for resale, because they don’t get repeat business.

    A business model also apparently used by the Obamacare software makers.

  2. “Software doesn’t scale in a linear fashion.”

    There’s a joke about how if it takes one man five days to paint a house it takes five men one day to do the same thing, so if it takes one man ten days to swim across the Atlantic it should take ten men only one day to do the same thing. It’s Math! It’s irrefutable!

  3. “They claim it will be working by the end of November? Did they say which November?”
    That’s the trouble with government programs. It insists that engineers think like lawyers, when we have enough people thinking like lawyers already!

  4. Who did California’s OCare website? From what I understand, it works. Couldn’t they just ramp it up to cover more states?

    • I don’t know and don’t much care about the answer to the first question. It could be that it does work well.

      The first problem I see, and there are probably a lot more, is that the Fed site performs much different tasks. It communicate with all the state databases. The state website communicates with the insurance providers.

  5. I would offer that when the fundamental concept the website is based on is broken, then the operational capability of the website is irrelevant…

    • True. But that is a much more difficult sell than to point out the obvious problems with the web site.

Comments are closed.