Healthcare.gov’s Problems Were Predictable, Says Computer Science Guru
Without strong management, complicated software projects are debacles waiting to happen, said longtime UNC computer science chair Fred Brooks.
By Rose Hoban
As the rollout of the Affordable Care Act’s signature health insurance shopping website, healthcare.gov, stretches into a month of problems, UNC-Chapel Hill computer science professor Fred Brooks said he’s not surprised by the debacle.
Brooks should know. He helped design and create the operating system for the IBM mainframes in the early 1960s. The descendants of that system undergird many large operating systems in use today, such as those for credit card transactions. At the time, it was the largest programming project ever undertaken.
Brooks then went on to lead UNC’s computer science department for two decades.
More significantly, Brooks penned the seminal text The Mythical Man-Month in 1975. The book is still taught in systems engineering programs around the world and it’s where he made the observation known as “Brooks’ Law”: When you add new people to a complicated software project, it actually slows things down.
“When you add new people, someone who was building the system has to stop building and teach the new people,” Brooks explained. Then the work needs to be divided up into more parts, and new interfaces between all of those parts need to be defined, further complicating and slowing progress.”
“So, what I say is that many hands make more work, all the time, because of that division,” Brooks added.
Brooks noted that no one seemed to be overseeing the entire heathcare.gov project.
He explained that successful software projects have a clear concept in mind and relatively few minds thinking about the structure and the user interface.
Brooks pointed to the example of Marissa Mayer, who led the team determining the user experience at Google for years before heading to Yahoo! to serve as CEO. He said one of the reasons Google products look similar across different uses is due to Mayer’s relatively small team thinking about the ways users interact with the web, and then getting the engineers to carry out their vision.
And once the project has a strong leader, with clear visions, the tasks can be divided efficiently.
“One of the serious concerns is that there were multiple contractors with no one in charge, and the federal agency doing the system integration, and that’s the hardest part of the job,” said Brooks of healthcare.gov. “They didn’t have the experience necessary to do that.”
He also critiqued government managers for not listening to the engineers working on the project.
“All the evidence is that the engineers said this is not ready, this hasn’t been tested enough,” Brook said. “But no one told the president. So someone in between didn’t have the courage to take that bad news upstairs.”
He compared that to management’s reluctance to listen to people actually doing the grunt work to the failures that caused the explosion of the Space Shuttle Challenger in 1986. In that instance, “engineers at Morton Thiokol said don’t go … but government officials said you have to go,” Brooks recalled.
Mid-level managers may have thought they were shielding their superiors… but they were making more problems in terms of trouble and embarrassment, Brooks said. “And if you want to fix blame, fix blame on whoever decided to go against the technical opinion of the people building it.”
Brooks expressed skepticism that a “tech surge” would be the answer, because, by definition, a software project is not easily broken up into discrete parts that can be solved and accounted for easily.
“The extreme example would be that assigning nine women to the task doesn’t make it possible to have a baby in a month,” Brooks said.