Among many possible excerpts, let me pick
On a major new tech project, you can’t really understand the challenges involved until you start trying to build it. Rigid adherence to detailed advance planning amounts to a commitment by everyone involved not to learn anything useful or surprising while doing the actual work. Worse, the illusion that an advance plan can proceed according to schedule can make it harder to catch and fixed errors as early as possible, so as to limit the damage they cause. The need to prevent errors from compounding before they are fixed puts a premium on breaking a project down into small, testable chunks, with progress and plans continuously reviewed and updated. Such a working method, often described as “agile development,” is now standard in large swaths of the commercial tech industry.
The whole essay is here.
Another excerpt:
NASA didn’t figure out how to put a man on the moon in one long, early burst of brilliant planning; it did so by working in discrete, testable steps. Many of those steps were partial or total failures, which informed later work. In digital technology, such an incremental, experimental approach is called “test-driven development.” It has become standard practice in the field, but it was not used for HealthCare.gov. Tests on that site were late and desultory, and even when they revealed problems, little was changed.
Shirky’s essay is ok as far as it goes, but I think that what needs to be emphasized is that the Obama Administration was launching a business. Call it a health insurance brokerage business if you like. It is just as important to take “an incremental, experimental approach” in launching a business as it is in creating a web site. Also, when a business gets launched in the market, its failure causes little notice. For every spectacular success, there are dozens of just so-so businesses and hundreds of total failures. When the government uses its monopoly power to launch a business that everyone is “mandated” to use, this precludes the learning that takes place in markets.
The failure of Obamacare is larger than the failure of the web site. Treating it as a technical failure allows progressives to avoid facing that fact.
This is the case with law in general. In many cases, it is possible to allow case law to advance and only codify or modify it after the fact, but this can’t be done up front with something like health care that needs much authority and control to work. Does anyone think Congress would create the NHCA and give them carte blanche powers to re-organize health care? Certainly it created some smaller units with more delimited powers but it not only has to work but work within the system as it exists with all its failings, doing as little as possible to disturb entrenched interests.
I see an additional analogy. When a business goes to replace a big complicated system, the agile approach usually does not work well. The reasons are:
– Users are already having their needs met by the existing system to some degree.
– The reason for replacement is usually architectural, not functional.
– Either (1) the new system’s architecture must either accommodate all of the extraneous little features that have grown on to the original system over time or (2) the system owner must decide to jettison those features (and, implicitly, the users who value them most highly).
– The “minimum viable product” (which agile programmers think about) is usually something close to the entire system. It certainly requires the technical architecture for the entire system.
These issues mean that there is a huge amount of design required ahead of time. That has to be coupled with extensive testing to make sure that the new system does what the old one did.
To carry the analogy out, Obamacare was a replacement for a dispersed system of private brokers and decision-making. The “designers” were clearly intending to jettison many features of the old system. And the minimum viable system was very large. The fact that users did not receive all of the features that they expected should not have surprised anyone.
Now note that I have not mentioned software.
In my experience, tech problems are nearly always management problems. The engineers want to do it right, but when faced with competing objectives they will compromise. The testing people really want to make it perfect, but when faced with threats to release it by the end of the month or else, they will rubber stamp it. The customer support people really want to make it work for the customers, but when the product is crap they get tired of apologizing really fast. Yes, I understand that intense competition and short product cycles are the nature of the business, but it still angers me when I hear the managers blaming the technicians for the failures.