by By Sam King*
Bad technology is pervasive, but it doesn’t have to be. Healthcare.gov’s initial problems threatened to derail the Affordable Care Act and took a tremendous effort to fix. The Department of Veterans Affairs (VA) has 98,000 disability claims that have been in a backlog for over 125 days, partly because the technology wasn’t adapting to changing needs. The Mars Climate Orbiter crashed because NASA used metric units and Lockheed Martin used English units. Because of many issues like these, technology developers have come up with different cultural narratives about why problems happen and how to prevent them.
One narrative blames change and tries to control changes using policy. An organization with this cultural narrative would have a process for each part of software development and would make detailed plans and requirements so that no change is unexpected. However, requiring Lockheed Martin to use metric units doesn’t mean they’ll do it. Technology development is full of uncertainty and complexity, so the best laid plans often go awry.
The other narrative accepts that change is inevitable, meaning technology developers should adapt to change. An organization developing technology with this cultural narrative would focus on teaching principles like humility, flexibility, and accountability to its employees and clients. The Centers for Medicare & Medicaid Services (CMS) got healthcare.gov working after its initial failure by being flexible enough to try new things when their established processes didn’t work.
Embracing change rather than blaming it is scary. It means taking problems one day at a time and admitting that it’s impossible to control everything. A cultural change like that is hard, but as the VA’s backlog shows, waiting too long to change is risky. Thankfully, many in government are already taking the leap.
One key place for this change is in software development processes. CMS encourages technology projects to follow its Expedited Life Cycle (XLC) framework. I only bring up the XLC because of my time working on healthcare.gov and other CMS projects. It isn’t unique. There are similar frameworks across both the public and private sectors.
The XLC focuses on process and planning rather than adaptability. This framework is well intentioned: many software failures are attributed to changing requirements, and it’s reasonable to think that planning, documentation, and reviews would reduce last minute changes. However, the requirements often change anyways because there is so much uncertainty and complexity in technology development. That is why adaptability is so important. The XLC was not designed to support adaptation, and it acknowledges that change is difficult within its process. According to the XLC details, once a document gets to the “baseline” phase, “It is possible but usually difficult to change.” This is a problem because many documents are supposed to be baselined or finalized before implementation of the system even starts, which makes it difficult or impossible to both follow the process and adapt to changes during implementation. A technology development process should make change easy, not difficult.
Lightweight frameworks like agile development are often touted as solutions, but the XLC guidelines for agile projects aren’t enough to guide an organization on how to adapt to change. Talking to users, testing every change, and releasing code weekly would each help a project deal with complexity and uncertainty, but none of those practices made it into the agile XLC guidelines. On the other hand, with the right culture, technology developers would use practices like those even if the process didn’t explicitly require them. That’s why, when an organization wants to get better at technology development, it should give cultural principles at least as much focus as processes.
An organizational culture that adapts to change could center on a few guiding principles:
- Be humble. The first attempt at anything will likely go poorly. The product might not be what the user needs, so show users the product frequently. The code might be buggy, so use automated monitoring and testing. Releases might have errors, so release code early and often.
- Be flexible. The requirements and architecture will change, so plan one week at a time, design systems to be easy to change, and fix processes that get in the way.
- Be accountable. No one is perfect. People should feel empowered to point out problems, to admit when they’re the cause, and to take initiative in making a fix. Similarly, organizations need to reward accountability rather than punishing mistakes.
Culture is not a monolith, and there is no silver bullet that will fix all these problems, but there is cause for hope, not cynicism. Many organizations are humble, flexible, accountable, and focused on adapting to change. City governments are working with Code for America. Federal agencies like CMS are working with new groups. 18F is delivering technology for government projects and is making technical infrastructure more flexible. The US Digital Service is improving technology policies and publishing recommendations like the US Digital Services Playbook. These groups set an example that we should all strive to follow. The technology development culture is changing one organization at a time.
* Sam King is a computer scientist who has worked at for profits, non profits, and government subcontractors. This article draws primarily on his experiences at Google and healthcare.gov.