Our 7-part series featuring the team from BlockScience kicks off with Matt Barlin, Lead Systems Engineer, and Jeff Emmett, Communications Lead. Their wide-ranging conversation spans engineering ethics, its application to real-life projects, and the difference between web2 and web3 engineering methodologies.
Matt Barlin (MB) started his career as a Naval Architect and Marine Engineer specializing in moving cargo across oceans while solving associated economic problems. An MIT master’s degree in Oceans Systems Management got him deeper into digital electronics and data science, which led him to blockchain.
Jeff Emmett (JE) works in communications at BlockScience, where his engineering background proved valuable for taking a deep dive into the new design space of Token Engineering, which incorporates tools from many existing engineering disciplines. Jeff has been one of the early advocates for establishing safe and ethical Token Engineering in the web3 space.
Eugene Leventhal, the Executive Director of SCRF, hosted the discussion.
MB: The software ethos millions of web2 coders grew up with was, “go fast and break things.” But in blockchain, an engineer oversees critical systems that will underly economies for the indefinite future. They don’t want to go fast. They want to go slow and get everything right. The slogan of every major engineering company is always some variation of “building a better world.” Engineering ethics means holding onto that. The web3 systems designed and built right now are economical and digital; they consume energy and affect real people’s lives. Designers have to take on that responsibility. They can’t just say, “I slapped that together quickly, and it mostly works.” People can get hurt by what occurs deep in these systems, and that can’t be taken lightly. Designers and builders need to adopt a “do no harm” principle.
JE: This is one of the missing pieces in web3 today. People write a white paper about what they’re proposing to build and then go straight to coding. Software may not be a physical object, but building unreliable infrastructure for a society still goes against the engineering code of ethics.
In the web3 world, is it fair to expect that a higher value will be placed on engineering ethics than we’ve seen in the last decade of web2?
JE: It hits a new standard when society mobilizes autonomous, self-executing smart contracts that live on a blockchain potentially forever and represent a whole new level of automation.
MB: There’s a lot that could be improved in going from web2 to web3: how data is used, how people give their data away for free, and how data may be used without people’s knowledge or based on terms that are understandably seldom thoroughly read. Web2 leads people to ask: Were there ever any engineering ethics involved? In web3, at a bare minimum, users should be fairly compensated for the things they give up to use these new systems.
Are there examples that would bring program design home to viewers? For example, if you’re designing a token, does the process always go back to fundamental questions like, “Is a blockchain needed? If so, is a token necessary?”
MB: If it’s an immature or brand-new project, the answer is probably yes. But for mature projects where the engineers have already answered those questions and are now adding other functionality, probably not. There are already some components that will be interfaced with, and those components have likely generated data that can be tested against.
Is engineering methodology a constant lens applied at every step of the design and build process? Or are there specific milestones more appropriate for questioning methodology?
MB: Web3 provides some natural advantages. One is the code’s transparency, typically running on publicly available blockchains that anyone can verify. Another advantage of these generalized, dynamic systems is that you have an “admissible action space” where you can build roadblocks if there’s something specific that shouldn’t happen.
JE: Another term core to all engineering operations is “bounds of operation,” which rests on the engineering adage “all models are wrong, but some are useful.” When engineers produce a component, they expect it to operate well within certain conditions. Nothing works equally well in all circumstances. In the physical world, for example, this might affect the choice of glue used in a project that is guaranteed to work up to a certain temperature level. Similar expectations come into play in the non-physical world where the component is, say, a crypto-economic protocol. The designer is still thinking about the entire life cycle, the assumptions made, and the bounds of operation.
If you were to provide one takeaway that you wish more people venturing into web3 would keep in mind when they set out to design and build highly complex things in this space, what would it be?
JE: One thing that people tend to oversimplify is the evolution of web3 and where it stands. It’s in its infancy. A company building a new token might hire one token engineer. As the space evolves, many other groups will become involved.
MB: And we have a responsibility for education. To follow the metaphor, companies may need to establish something like “token engineering academies” that take responsibility for imparting the best practices we’ve learned as we came through the process. In the end, if this is going to become a discipline, all parties must help each other.