The Offensive Linemen of Blockchain Development
This post doesn’t make any assumptions about whether you believe blockchain is the future of mankind — and that future is right now — or you feel scalability, security issues and transaction costs will plague it for the foreseeable future. It just aims to bring awareness to what, in my opinion, is the greatest and least discussed risk of all blockchain projects. I used a football metaphor about offensive linemen in the title of this article because without an offensive line no football team can succeed, but they still never seem to get much credit. I believe the same analogy can be applied to the process of development and QA in the blockchain world.
In all of the excitement about decentralization, immutability, trust-less ecosystems, consensus mechanisms, self-sovereign identities, etc, the fact that smart contract code not only needs to be secure but also actually needs to work correctly (and be accompanied by a user-friendly interface?) seems to get lost as just another implementation detail. Sometimes amidst all the hype, we need to remind ourselves that users don’t care about Dropbox’s cloud architecture or what databases Google uses; they care about being able to do what they want easily and reliably.
Even amongst non-blockchain startups, I’ve observed that QA, testing automation, and basic functional testing often take a backseat to other development, product and marketing initiatives. This usually does not lead to very good results or a ton of success. So, when you take this trend and combine it together with projects whose primary focus is centered around their data architecture (which is almost always abstracted away from the way a DApp is ultimately judged — does the code execute correctly and can the user understand it), you have a very potent recipe for disaster.
Separately, the highly publicized hacks of large blockchain projects (Mt Gox, DAO, Parity, etc), combined with the hype around ICOs, have led to a major emphasis on security. They also aim to fulfill the prophecy of being less easily hacked than traditional web applications. This has led to a number of security audit companies springing up in this niche to help the community.
However, I am concerned that all of these elements combine to obscure the (un-sexy) fact that the most important element of a successful protocol or application is that it actually works as expected, and people can figure out how to use it. Even with an application as secure as Fort Knox, if you forget to install a front door or accidentally make elevator buttons that take people to the wrong floor…nothing else will matter. It is encouraging to see frameworks like Truffle offering built-in support for automation testing. I hope people developing blockchain applications will learn lessons from the “traditional” startup graveyard and keep in mind that excitement about blockchain technology may help with early credibility and momentum but probably won’t have much to do with long term retention or success.