When Software Fails

What happens when the blueprint for so much of our technology no longer suits our needs? No-code can take up the charge.

It may be time to reevaluate our relationship with code. Airport departure management systems, 911 switchboards, and even the New York Stock Exchange are powered by it. But with all of these critical systems reliant on lines upon lines of code, the slightest bit of human error can have huge implications. Poorly-written code was a factor in the grounding of an entire fleet of United Airlines flights in 2015, at least one 911 outage per year since 2014 and, most recently, the debacle at the 2020 Iowa Democratic caucus. 

These examples of the potential shortcomings of code don’t necessarily mean that we’re on the brink of a “software apocalypse,” as James Somer put it in a 2017 story for The Atlantic. But it does mean we should be open to thinking critically about how it often fails to meet our needs, why that happens, and if there might be an alternative.  

The Real Problem with Code

Code becomes a problem when the software it power becomes so complex and unwieldy that the programmers who wrote it become alienated from their own product. 

We can think about a program’s code as a collection of potential decisions to be made—if this, then that. Each of these decisions spawns its own set of subsequent decisions, which spawn their own, and so on. Programmers can measure the complexity of their software by taking stock of the number of independent paths created by these decisions, a metric known as cyclomatic complexity.

When programmers code, they are typing characters into a text editor that will eventually represent the functionality of the software they develop. There isn’t anything inherently wrong with this—in fact, we’ve relied on this method of development for decades. The difference is that 30 years ago, programmers could realistically build and test all possible outcomes of their code by manually exercising all execution paths. 

Naturally, as the cyclomatic complexity of modern software has increased, it’s become impractical to test all of a program’s possible paths. For instance, there is no way humans can verify and test the billions of lines of code required to run a Tesla. The software we rely on has become so complex that it is no longer possible for programmers to manage code at scale. Instead, programmers simply have to write much of their code with faith that everything will work out. 

Asking any human to juggle this many complex rules is a tall order. Translating individual functions into a programming language is difficult enough, let alone trying to do so while keeping in mind a picture of the decision tree that represents the entire application. This complexity necessarily removes programmers from the larger problem they set out to solve. In other words, code causes a disconnect between programmers and the software they create with it.

“Inventing on Principle”

In 2012, computer scientist Bret Victor gave a speech titled “Inventing on Principle.” In it, Victor argued that the reason why code fails so often is that programmers must have a tangible connection to what they’re creating to be successful, meaning they need a way to manipulate software’s inner workings and see the effects of their actions in real-time. Code can’t offer that.  

Victor envisioned a paradigm shift toward a model-based approach to coding. In a model-based approach, programmers are given rules for how the software must behave, which shifts the focus from using code to translate rules to using code to work within the rules and solve problems. Victor believes that coding should resemble working in a responsive environment—for example, a Microsoft Word document. If you want to italicize a word, all you have to do is highlight it, click the italicized “I” in the toolbar, and you instantly see text changes on your screen. You’ll know if something’s right or wrong immediately—no waiting, no guessing, no disconnect.

The complexity of modern software demands that a huge portion of a programmer’s job is focused on essentially translating functions into a programming language, rather than truly problem-solving and innovating—or in Victor’s words, “inventing on principle.” When problem-solving becomes secondary, it can be incredibly frustrating for developers. 

We at Unqork understand these frustrations with traditional coding, and have made it our mission to create tools that break down the barrier of code between programmer and product. But we also believe that our mission isn’t just about eliminating frustration—a disconnect between programmer and product inevitably leads to critical failures. 

The High Costs of Failure, and the No-Code Solution

This disconnect between programmers and the software they build has serious implications when we think about how much of everyday life depends on software—from cars to mobile applications. When software fails as a result of “broken” or buggy code, it can have disastrous consequences. What’s more, it’s very difficult to rapidly address failure or prevent it in the future because the complexity of a modern piece of software makes it nearly impossible for programmers to see what’s wrong until it’s too late. 

However, it’s not entirely fair to blame buggy code alone for software failures. Consider the 911 outage in Washington in 2014. The system was built to keep a running tally of how many calls transferred to 911 across the country, and the threshold was set in the millions. But when the tally exceeded that number in April of 2014, the servers stopped generating unique identifiers for each call and started dropping calls instead. There were backup protocols in place in the event of a crash, but the software hadn’t been coded to automatically fall back on these protocols in the event of an emergency. 

In truth, the 911 system did exactly what it was designed to do—but it was designed to do the wrong thing. Software failures are not mechanical. They are failures in understanding, imagination, and scope caused by barriers between programmer and product. If programmers remain disconnected from their work due to the complexity and the nature of the work, it simply isn’t feasible for us to rely on software as much as we do today.

Looking Ahead 

Eight years after Bret Victor described his vision for model-based development, no-code is bringing his vision to life. The Unqork platform still allows creators to build incredibly powerful and complex software—just without needing to translate thousands of lines of code to get there. Unqork eliminates code altogether and allows creators to build and validate software within a visual interface.

Unqork output is live and ready for use as soon as it’s created, so developers can repeatedly test their applications and pinpoint any vulnerabilities before they become full-blown software failures. Perhaps best of all, Unqork allows the people who best know the requirements of the product to create the logic that powers it. 

No-code isn’t just about making programming easier and faster (although it does!)—it’s about making software as a whole less vulnerable to failure, and more likely to perform as intended.