Fee-for-services coding like fee-for-services health care. Fail!
Well, it seems that the same fee-for-service mentality that makes a muck of health care made a muck of the health care exchange website, meant to solve that very problem.
If, as estimated by some commentators, five million lines of code need to be re-written to fix the government's health care exchange website, that likely means the program is too big and cumbersome to run well.
The New York Times reported that the number of lines of code in that website is as much as five times that of a typical large bank's website.
Why would the heathcare.gov website be designed in such a way by an outside contractor? Because coders often price jobs by the number of lines of code they will have to write.
According to Will Oremus of Slate, this gives developers a disincentive to write elegant code that might provide simplicity and few opportunities for errors.
He quotes Steve Ballmer from a 1996 film, Triumph of the Nerds:
In IBM there's a religion in software that says you have to count K-LOCs, and a K-LOC is a thousand lines of code. How big a project is it? Oh, it's sort of a 10K-LOC project. This is a 20K-LOCer. And this is 50K-LOCs. And IBM wanted to sort of make it the religion about how we got paid. ... And we kept trying to convince them--hey, if we have--a developer's got a good idea and he can get something done in 4K-LOCs instead of 20K-LOCs, should we make less money? Because he's made something smaller and faster, less K-LOC. K-LOCs, K-LOCs, that's the methodology. Ugh! Anyway, that always makes my back just crinkle up at the thought of the whole thing.
Sounds a bit like the health care system, where hospitals doctors and labs have a disincentive to get patients well. The more goods and services they provide the more they get paid, regardless of outcome.
If pricing were based on results -- does the software accomplish its purpose with a limited set of problems or bugs -- then coders would have more incentive to craft elegant solutions and those who purchase these solutions would get leaner less problematic software.
Plus, this sort of arrangement rewards the best programmers by paying them well to write fewer lines of code.
What should we learn from this? Metrics, folks, are insidious things that are never inevitable in their origins. They are the products of specific interest groups and generally are devised to maximize income for somebody.
The rest of us need to take a step back from all the many metrics we take for granted and ask ourselves is this the right metric? What might make more sense?
In the case of health care, positive outcomes over time for patients might be the best metric.
In the case of software developers, paying them to create an efficient black box -- one that gets the job done right, with the fewest problems -- would be a far better metric. Buyers don't need to know how many lines of code are inside the box, only that it works.
In government, we reward politicians with ongoing employment, based on a system whose chief metric is how much money they can raise. The outcomes speak for themselves. That, dear reader, is another metric worth re-evaluating.