I spent the summer of 2010 as an engineering intern at Google. During my 14-week internship, I spent the majority of my time on one project: adding a field to a database in Google's ad-sales system. Eventually, another Google employee would use the data in this field to add a checkbox to a search interface used by Google's ad sales representatives.
You might think that isn't very much to accomplish over a summer, and you'd be right. An experienced Googler probably could have performed the same job in a couple of weeks. But my lack of productivity wasn't because I was a terrible programmer. Rather, Google's software is so complex that it took the better part of the summer just to "learn the ropes."
The experience makes me skeptical that the "tech surge" the Obama administration announced on Sunday will significantly speed up the process of fixing HealthCare.gov. Adding more programmers to the team trying to fix the site is unlikely to speed up the process, and might even slow it down.
During my internship, I spent the bulk of my time reading code and documentation to help me understand how Google's existing software systems worked. When I got stuck, which happened fairly often, I'd ask my supervisor to help me out.
Sometimes it took her more time to guide me to the right answer than it would have for her to simply write the code herself. Indeed, if you add up all the time she spent training and supervising me, it's not clear my net contribution to the organization was even positive.
Admittedly, I was a relative beginner with limited experience in commercial software development. If Google had hired an experienced programmer instead, that employee would have been able to get up to speed more quickly. But even the most talented and experienced programmers face a significant learning curve when starting a new job.
And I had some advantages that new programmers joining the HealthCare.gov team will not. The software I was working on was well-designed, and my supervisor gave me a relatively straightforward task to complete. In contrast, the HealthCare.gov code is apparently a mess, and no one is sure what needs to be done to fix it. Moreover, fixing the system may require the kind of serious overhaul that can only be undertaken by someone with an intimate knowledge of the system.
Not only will more programmers not necessarily speed up the development process very much, it could actually make things worse. That's because existing programmers will need to spend time training the new programmers, assigning them tasks, and coordinating their efforts with the new, larger development team. Just as supervising me may have taken my boss more time than just doing the work would have, so adding more people to the HealthCare.gov team may actually lengthen the time it takes to build the HealthCare.gov Web site.
This phenomenon, in which adding people to a late software project makes it later, is known as Brooks's Law. In the mid-1960s, Fred Brooks managed the project to build OS/360, a complex IBM operating system for mainframes. In 1975, he wrote a famous book called "The Mythical Man Month" about the experience.
"When schedule slippage is recognized, the natural (and traditional) response is to add manpower." Brooks wrote. "Like dousing a fire with gasoline, this makes matters worse, much worse."
Brooks counseled patience, warning that throwing more resources at a software project may be counterproductive.
"An omelette [sic], promised in two minutes, may appear to be progressing nicely. But when it has not set in two minutes, the customer has two choices—wait or eat it raw," Brooks wrote. "Software customers have had the same two choices."
"The cook has another choice; he can turn up the heat. The result is often an omelette nothing can save—burned in one part, raw in another."
Right now, HealthCare.gov is an undercooked omelet. The Obama administration needs to keep the dangers of Brooks's Law in mind, lest adding manpower to the project burn the omelet.