To be sure, the politics of the bugs in the federal health care exchange are unbecoming. But the media, and everybody else, should know that these bugs have nothing to do with any inadequacies in the Affordable Care Act and everything to do with the all-to-common mistake of underestimating how long it takes to build software.
For a living, I design and develop databases and write code for web applications—web application like the federal health care exchange found over at HealthCare.gov.
I just completed an application for a professional association seeking to collect employment, education, expertise, and demographic data from its membership by asking its members to complete an optional profile. Nearly a year passed between the time that I received the functional specifications (a written document describing how the website would look and work from a user’s point of view) to the time that this application was deployed. Note that my boss had told his boss that it could be completed in about three months, give or take.
From the user’s perspective this online survey is fairly easy to use and can be completed in less than five minutes. From a development standpoint it was very time consuming and complicated application to build, especially because the questions that the users see vary depending on the responses that they give to previous questions. Of course, users don’t know that when completing the survey, but these contingencies complicated the task of building the application immensly.
The point that I’m making with this illustration is that designing and building a website, and the database behind it, takes time—always more time than we expect… More time than users would expect when using a well-designed, easy-to-navigate site. More time than experienced technology managers expect when throwing out bogus estimates for their bosses. More time than even we software developers expect because of changes that are continually requested as the software is being built, unexpected coding and database obstacles that always arise, time-consuming validation that must be added to all online forms to prevent users from accidentally entering bad data (e.g., an invalid e-mail address format or an invalid zip code), and the unexpected monotony of writing if…then statements for scores or hundreds of possible user contingencies that simply can’t be anticipated until the code is actually being written.
In fact, we software developers suck at estimating how long it will take to build a web application (it’s time that we admit that). So, if we suck at it, imagine how poorly our managers who have never written a line of code suck at it when they pull estimates out of their asses to impose on their development teams and report to their bosses.
Here’s a quick tip. If you ever hire a software developer or software team first ask them how long it will take to build an application. Then, when asking this question, know that that developer is a) not sure and b) wants to tell you the shortest time possible for fear that your eyes will pop out when you hear the truth. Finally, take your developer’s estimate and mulitply it by four. If your developer estimates that he can finish an application or new feature in three months, then expect it to take a year. Then, and only then, might you get lucky that the project will come in on time and within budget.
Note also that throwing multiple developers on a software project does not necessarily speed up development. Many, if not most, components of a software application should be developed in succession in order to for them to properly work together. As a result, most significant projects have one or two developers working on them at time. Any more than that is frequently a “too many cooks in the kitchen” situtation.
So, what’s the lesson here for the federal exchange at HealthCare.gov. Well, the New York Times reported that the developers didn’t get started until this spring.
The biggest contractor, CGI Federal, was awarded its $94 million contract in December 2011. But the government was so slow in issuing specifications that the firm did not start writing software code until this spring, according to people familiar with the process.
Assuming that they’re talking about March, that gave the development team six or seven months to build, test, and deploy a complex software application intended for millions of users.
So whoever decided that it was okay to deliver functional specifications for this application as late as last spring while promising that the site could be ready by the beginning of October, in my view, is the person responsible for the HealthCare.gov debacle. In other words, the person who had the authority to set a reasonable deadline for the functional specifications for the exchange, but didn’t, fucked-up. I don’t know that person’s name, but he’s your man (or woman).
10-22-13 UPDATE: The AP published this piece today. Here's an excerpt:
Project developers for the health care website who spoke to the AP on condition of anonymity - because they feared they would otherwise be fired - said they raised doubts among themselves whether the website could be ready in time. They complained openly to each other about what they considered tight and unrealistic deadlines. One was nearly brought to tears over the stress of finishing on time, one developer said. Website builders saw red flags for months.