Five Million Lines

Five million lines.   That’s one estimate of the amount of code that will need to be rewritten to get Healthcare.gov to a consistently functional state.   That’s 5 million out of a total of 500 million lines of code in the entire site.  To put that in perspective, the entire Windows Vista operating system is about 50 million lines, or one-tenth the size of that.  Any software engineer realizes that 500 million lines of code is a severely bloated program, even if that code is using the latest, trendiest open source technologies and architectures.  So how did the system end up in this mess?  

Poor project management, for sure.  According to congressional testimony, most of the contractors were working in isolation, and very little, if any time, was left to test the fully integrated solution.  And all of the contractors spoke of late requirements and last-minute changes requested by “the business.”  Over the next few months, congressional oversight committees and blue ribbon commissions will examine the root causes and lay blame.  Some will end up at the feet of the contractors who built the system, and some at the government who managed and funded—or failed to manage and failed to fund—the work.

But perhaps some of the blame should be laid at the practice of software engineering itself.   Take away Jeckyll and GitHub and Rackspace, and you find that Healthcare.gov was built exactly the same way that the first Medicare systems were built in the late 1960’s: elaborate requirements documents written by business experts were painstakingly interpreted by technical experts and manually translated into text files of containing code.  In the days since Medicare, that syntax of the code has changed (COBOL and PL/1 and Assembler to HTML5 and CSS3 and Java and Javascript). But the process hasn’t.

Building massive, complex systems is hard work. But we don’t make it any easier when we force business stakeholders to specify all of their requirements into documents that give no indication of what the final system will look like or what it will do.  We don’t make it any easier when we resist last minute changes, instead of expecting them.  We don’t make it any easier when we separate the stakeholders of the application from the technology that will implement it.

There is a better way.  At Pega, we have shown that it is possible to build complex, powerful, mission-critical applications without millions of lines of code.  Instead of cryptic text, these applications are built by leveraging model-driven tools and business concepts like process models, case definitions and business rules.  This “build for change” approach allows stakeholders to capture their requirements directly in the technology, immediately see the resulting system and collaborate iteratively with technologists to deliver exactly the systems they need.  Some of the world’s largest banks, insurers and healthcare companies run their core business operations on systems built this way. 

Better than that, they are able to change and evolve those operations to meet competitive demands, support regulatory requirements and innovate their business while delivering extraordinary service to their customers.  And they certainly don’t need 5 million lines of code to make that happen.