Helping you drive digital innovation
Subscribe
RSS Feed of the Mendix Blog
Thanks for Subscribing

Keep an eye out for Mendix resources coming straight to your inbox.

The Key to Avoiding the Next Healthcare.gov Disaster: An Open Letter to White House CTO Todd Park

on November 1, 2013

Share:

Dear Todd Park,

The technical failure of Healthcare.gov has received considerable media attention over the past week.  Everyone has an opinion about why the health exchange failed, and while it’s easy to blame individual agencies or contractors or even pieces of technology, there’s a much more systemic issue at play here. To paraphrase the old Clinton campaign slogan, “It’s the code, stupid.”

As you know, Healthcare.gov is predicated upon 500 million lines of code—five times more than a large bank’s computer system, according to the New York Times.  This staggering amount of code highlights the root cause of many software project failures.  With traditional code-based development, the process of translating user requirements to software is too complicated, too lengthy, and too risky.  Mission owners (or business stakeholders) and software developers simply lack a common ‘language’, which in turn, becomes a barrier to iterative, collaborative development that allows for quick results.  As a result, functionality cannot be developed fast enough; the product cannot be reviewed and tested by users throughout the process; and changes cannot be introduced easily, without derailing the entire project.

While straight-up software code has been the foundation of millions of systems for decades, the failure of Healthcare.gov makes painfully clear how risky such projects are (according to the Standish Group, 94% of large IT projects are in trouble or fail altogether) and just how much times have changed. Project timelines are shorter, requirements routinely change, systems are more interconnected, users expectations are higher in our always-on economy, and IT and government/business must work together more than ever.  As a result, government agencies and businesses that continue to rely on traditional code-based development will end up among the 94% of distressed IT projects.

One language for all

The Healthcare.gov fiasco could have been avoided—and hundreds of millions of taxpayer dollars saved—because times have also changed from a technology perspective.  Over the last few years,  visual, model-driven development has emerged as the new application development paradigm because it breaks the decades-old business-IT divide, improves project success rates dramatically, and delivers working applications in a fraction of the time.  In contrast to old, code-based methods, model-driven development allows all parties involved in the project to understand and speak the same language. They can see results quickly (in days not months or years) and then jointly identify and make adjustments.  Consequently, the risk is removed from the process and the outcome is far more successful.

Interestingly, this new approach in many ways harkens back to the founding principles and beliefs of this nation.

Applications by the people, for the people

When you replace code with visual models that can be understood by all, the application development process is democratized.  Suddenly, everyone—even non-technical project participants —can take part in the process.  The entire team can collaborate on, and review, the application model, quickly understand the functionality, and easily identify course corrections.  And because the model is not only a visual model, but at the same time the actual running system, nothing gets lost in translation.

Unfortunately for Healthcare.gov, we have seen yet again the common disconnect between user requirements, software development, and deployment of all the pieces in the real world.  What was needed was a better mechanism for the development team to respond to changing requirements quickly and to align and engage all stakeholders throughout the development process. By having a common language and a way to collaborate and communicate in real time, the pitfalls that come with the old code-based approach could have been avoided.

I invite the White House and Centers for Medicare and Medicaid Services (CMS), as well as other government agencies and private sector companies who may be shying away from development projects because of Healthcare.gov, to take a few minutes to learn more about this next generation model-driven development approach.  It’s an entirely new way of developing software applications that allows all stakeholders – users, mission owners, business, process experts, and software developers – to design a system jointly, using a visual model everyone can understand, make changes as needed, and build a complete application without things getting lost in translation. As a result, you get the system you need – at a fraction of the time, cost and risk you have learned to live with.

Before anyone invests hundreds of millions in the next highly-publicized failure, remember, “It’s the code, stupid.”

Sincerely,

Derek Roos
CEO and Co-founder, Mendix

Subscribe to Our Blog

Receive Mendix platform tips, tricks, and other resources straight to your inbox every two weeks.

RSS Feed of the Mendix Blog
Derek Roos

About Derek Roos

As chief executive officer, Derek leads a pioneering team of software industry experts with the mission to bridge the gap between business and IT, making business application development dramatically easier, faster and collaborative. As a result, the company is achieving tremendous global growth and disrupting the way many of the world’s leading companies are innovating and differentiating. Derek earned a Master of Science degree in Business Administration from Erasmus University, Rotterdam. He is a highly sought speaker at IT conferences and is guest lecturer at several universities. Derek has received the Ernst & Young Emerging Entrepreneur of the Year 2012 Award. Keep in touch at @MendixCEO.

  • Chris Hall

    We will have to wait to find out if the 500,000,000 lines of code figure turns out to be correct. It is such an enormous figure that I have my doubts. What we do know is that this is one of the biggest software screw-ups in history. I think it is too early to say, though, if the reasons you suggest for project failure are indeed the correct ones.

  • informatimago

    Given the amount of copy-and-paste coding I see around me, I’d not be surprised if it was 500,000,000 lines of code.

  • geot2

    I worked at a software company that was really dedicated to supporting one insurance company. Let’s say it was just in one state (it was not!) But I’d be looking at 10,000,000 lines of code here? It does seem excessive.