Crypto Needs a New Development Paradigm
Blockchain development is hampered by systemic issues
Something is broken in blockchain development. We hear about hacks in crypto all the time, the industry is filled with hastily developed products, and project delays are often expected. The common wisdom is that this is a talent shortage: blockchain is a new space, and developers are still learning the language and the tech. Without talent, development is slower, security audits (reports from a third-party team of developers who stress-test code) are more expensive, and mistakes are more frequent. This view leads people to assume the market will self-correct as developer numbers increase and the industry gains experience.
But the problem goes beyond talent. Many projects with plenty of resources have faced exploits and delays. For instance, THORChain which was founded in 2018 and currently has a $2+ billion market cap, was hacked three times this summer for $13+ million, and the Ethereum 2.0 Beacon Chain launched almost a year after its original deadline. Even with long development timelines, plenty of capital to compensate developers, and multiple rounds of audits from top security firms, exploits still occur with some regularity. This suggests it’s less a talent problem than a systems problem.
Traditional software development has three approaches
It seems increasingly clear that all three of the main paradigms of traditional software development fall short when applied to crypto.
Waterfall development was the predominant paradigm of the pre-internet era, when software ran on desktops and mainframes and updates were delivered via disk. The definitive example is Windows, which delivered a new version via CD-ROM every few years. AOL similarly sent out millions of CDs in the early 90s to get people online. Waterfall requires a huge amount of upfront planning, which developers then implement and firms ship. Changes are expensive and highly discouraged. The main shortcoming is that firms do not always know what customers want in advance, and missteps tend to torpedo years of work. In addition, developing all those features upfront is laborious and often results in unpredictable timelines and delays. Still, back then waterfall was the most effective development model given the constraints.
The internet’s ubiquity spurred the emergence of the second paradigm, agile development. Updates to client applications could suddenly be delivered frequently, and almost imperceptibly.
As e-commerce expanded and broadband penetration spiked, more and more software could be delivered directly through a user’s browser, often eliminating the need for downloadable versions. Published in 2001, the Agile Manifesto presented the principles of the new paradigm: deliver early, expect errors and welcome change throughout the process. Products were launched while still in development and teams improved features based on user feedback, with updates and new features coming out as frequently as every week. Agile soon became the dominant development methodology, even as another paradigm took shape in the background.
In the early 2000s, an emerging tech wave embraced the concept of open source, exemplified most notably by the Linux operating system, initially developed by Finnish engineer Linus Torvalds. Open source code is open to the public, a sort of crowd-sourced collaboration: as of 2006, for example, just two percent of the Linux base code was written by Torvalds. Following this philosophy, the open source development paradigm involves minimal planning and often leads in unexpected directions, evolving organically from user contributions. Developers are naturally most interested in software they might use themselves, and open source development has generated amazing and inspiring development tools, such as Google’s Android, which is Linux-based. Where open source often falls short, however, is with consumer-facing products that are used by non-developers and with the grunt-work of software that’s dull but necessary, like bug-fixes. As a result, the most widely used open source projects are those used by developers, and projects tend to develop their own ecosystems in which private firms provide support and custom updates, like Red Hat for Linux.
Traditional approaches create massive problems in crypto
Blockchain development presents constraints that disrupt the above paradigms. For starters, it is highly adversarial, with hackers constantly working to break into protocols holding billions of dollars. Security is of the utmost importance because the tiniest of errors can be existentially costly. A major crypto protocol gets exploited every month or so, according to rekt, an industry news site. A recently discovered vulnerability in the comptroller vault of Compound, one of the oldest and largest DeFi projects, led to the accidental distribution of nearly $150 million. Even multiple audits can leave bugs in smart contracts, which means even the most reputable and established protocols could have flaws. At the same time, projects that rush to launch have a market advantage over those that take the time to ensure stable code.
How would the above paradigms respond? Waterfall would stress the process, increasing checks and balances, security audits, code reviews and so on. But a more robust process would mean a longer and more expensive development timeline in an industry already struggling with long and pricey development. Besides, perfection is impossible; just consider the vulnerabilities in Windows and related platforms. For instance, the 2020 US government data breach, which compromised an enormous amount of national security infrastructure, was due in part to flaws within Microsoft. Even third party audit firms hired at great expense make mistakes. Agile would attempt to address the issue with iteration and frequent updates. But a bug can cause the loss of billions of dollars in an instant; even a quick-fix response would be too little, too late.
Another constraint is that the blockchain is a decentralized permanent record; once code is published it is impossible to change. Even minor updates require the publication of an entirely new version and a wholesale user shift, which means the rapid-fire updates of agile and open-source would no longer apply. Waterfall would address this by attempting to predict ahead of time what users want, but this approach requires massive, high-risk bets. A few have done it successfully: Uniswap has published three versions in three years, each a wholesale change from the previous.
Other protocols have experienced initial success before fading away. Consider Swerve, a fork of Curve that vowed to give 100 percent of its token distribution allocation to liquidity providers. Within two weeks of its September 2020 launch, Swerve was approaching $1 billion in locked value (TVL) and offering some of the best rates on stablecoin swaps. A month later the liquidity incentives had ended and Swerve had become irrelevant. By early 2021 its creators had moved on to new projects. DeFi winds shift far too quickly for waterfall-style foresight.
The solution is a new paradigm
If the pre-existing paradigms are round pegs, crypto is a square hole. The frustrating results are there for all to see: long development timelines, frequent delays, regular bugs and hacks, billions of dollars lost, and unused vaporware. The dearth of talent and widespread inexperience are problematic, without a doubt. But the core problem is deeper, at the very foundation of our work. It’s somewhere between Brook’s Law from the waterfall age, which states that adding manpower to an already late software project will make it later, and the warning left behind by the third THORChain hacker: “Do not rush code that controls 9 figures.”
Back in the 1960’s, American philosopher Thomas Kuhn drew a distinction between “incremental science,” in which existing theories are added to and tinkered with, and “paradigm shifts,” in which past theories are discarded in favor of promising new ideas. DeFi’s massive amounts of capital and usage represent an unsolvable problem for the existing paradigms. Blockchain needs a new development paradigm to ensure this fast growing community is able to build safe and useful products.
