The ongoing difficulties with healthcare.gov have captured the nation’s attention from the first folks who attempted to register to the folks who write the code and of course all the way to the folks at the White House. Much has been written analyzing the situation from numerous perspectives. I just want to comment on one angle related to the software itself.
Paul Ford wrote an article for Bloomberg Businessweek reviewing the software challenges. In it, he nicely details the interdependent and interlocking nature of large software systems, addressing the hows and whys of building them (“Failure to Launch” 10/21/13–10/27/13, pp. 68–71):
“Software systems are so large now that they can no longer exist separately from other systems. Code always depends on other code. It’s never finished: Write a piece of software today, and you’re likely to be debugging it a decade later. Modern software development is more like sustainable forestry, where you expect to keep coming back to the same grove year after year. The technology industry has come to understand that software is a process. The U.S. government, however, keeps insisting it’s a product.” (p. 71)
As Ford explains, as long as people believe the myth that software is a settled product, we will continue to have these kinds of difficulties.
Another myth is that just by throwing more software engineers at the problem, we will solve it faster. To a degree, that makes sense, until you look deeper. In Scott Rosenberg’s interesting book, Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software (Three Rivers Press, 2008), he proves the opposite. As counterintuitive as it sounds, Rosenberg describes how putting more coders on a software project consistently lengthens the time to completion. This is due to the complex nature of coding coupled with the variations in personal preferences among the coders. If you want to understand that better, I highly recommend the book. It is a great read.
Love it or hate it, we live and die with our software. Sometimes it all comes together in terrific ways and sometimes it crashes. Some days you get the elevator and some days you get the shaft. But I still believe we can greatly improve our odds when we take the time to understand the bigger picture better before we dive into these projects.