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.
