The primary failing of the Obamacare rollout has been attributed to the software that runs the user registration and payment functions. Software development has often been referred to as a can of worms, and for good reason. In my past, I was a government contracting officer for dozens of contracts that involved acquiring both hardware and software. By comparison, the software was always much more difficult than the hardware to deliver on time and within budget. It is not at all surprising to me that the Obamacare software is creating all these delays. Here’s why.
Creating software is sort of like having four people begin building a house by each person constructing one-fourth of the house with the goal to meet in the middle. Without a significant amount of planning and coordination, nothing will line up when they meet in the middle. Now imagine that instead of four, there are 25 or more people and that the floor plan, materials, finished appearance and other basic parameters are being changed for some, but not for all, of these construction people.
This is what happens in almost every large software development contract. The original design, or scope of the project, always evolves as the project develops. This is called “scope creep” and is very common. Unlike a house, there are hundreds of ways to create software that will end up doing the same thing. Every programmer has his own style, specialties and preferences. If one programmer starts writing code and then quits and another takes over, it is often very difficult for the second programmer to use the first one’s code. On very large projects, many different programmers have to coordinate and adjust their own style while, at the same time, accommodating a constant flow of changes to the basic design.
There are, of course, well-established methods to manage such projects and to coordinate, document and accommodate changes. When these methods are used, the project goes very smoothly, but such careful management and documentation methods take time and effort and that costs more money.
Most people that do not understand the complexities of software development will often underestimate the time and cost to create it. This is a common mistake in many government contracts because the price and schedule are often fixed and frozen at the time of the initial contract award — before any work has begun. Usually, the contractor is motivated to bid the lowest price and fastest schedule in order to win the contract. This often results in a contract that is underfunded and has too tight a delivery date to properly design and manage the software development using the proper methods.
In the rush to keep to a short schedule and low cost, all that careful planning and coordination gets shortchanged or omitted completely. The end result, like the house builders meeting in the middle, is misalignment, missing or mismatched supports and interfacing pieces.
One aspect that even the best programmers have difficulty in designing properly is a foolproof user interface. The data entry screens that allow the end users to input information into the software have to be able to accommodate every possible mistake that anyone is ever likely to make. Imagine all the different ways that someone could enter something simple like their date of birth. Is the fourth month of the year written as April or Apr or APR, or 04/ or 4-? And what if they put in Apilr or Juny? Does the software reject it or correct it?
Tens of thousands of these kinds of decisions have to be made and coded into what is referred to as EDC — error detection and correction. If a good testing phase of the software development is done properly, EDC is easy, but testing is very time-consuming and expensive and is often done improperly or incompletely.
Of course, there is always the possibility that the programmers are just not very good. In fact, it is surprising how often this is the case in government contracts. Take, for example, a random contract like, oh, say, the Obamacare software contract. It was released to a company called CGI. CGI acquired a software development company called AMS, and CGI is using many of the AMS staff to manage and perform the Obamacare software development. On so important a contract, the government would surely pick a company with a great track record on its past software development contracts. Wouldn’t they?
According to government audit reports, interviews and press accounts, AMS-built computer systems sent Philadelphia school district paychecks to dead people, shipped military parts to the wrong places for the Defense Logistics Agency and made 380,000 programming errors for the Wisconsin revenue department, forcing counties to repay millions of dollars in incorrectly calculated sales taxes. AMS also went $60 million over budget on a contract with the Federal Retirement Thrift Investment Board, and virtually none of its computer code was used, according to a report by a U.S. Senate committee.
Lawrence Stiffler, who was director of automated systems for the thrift board at the time and a 25-year veteran of IT contracting for the federal government, said AMS was highly unreliable. “You couldn’t count on them to deliver anything,” he said.
Yes, software development is a difficult process, and if the programmers don’t mess it up, you can always count on the government to choose a contractor that will do it for them.
Tom Watkins lives in Montpelier. He can be reached at TomW@21vt.us.MORE IN Commentary
- Most Popular
- Most Emailed