Content
@
0 reply
0 recast
2 reactions
Alex Roan
@alexroan
Q: How can I write more secure Smart Contracts? A: By understanding this key principle: Smart Contracts are NOT SOFTWARE. Smart Contracts are HARDWARE. “Alex, WTF are you talking about?”… hear me out…
1 reply
0 recast
1 reaction
Alex Roan
@alexroan
For the past 20 years, writing software has meant iterating quickly: Getting an MVP out there ASAP, moving fast, and breaking things. So, what happens when something goes wrong? UI misalignment? No worries: 10-minute hotfix. 404 error? Release a patch. Impact: Low, Cost to fix: Low
1 reply
0 recast
0 reaction
Alex Roan
@alexroan
Software Engineers and Product teams approach software this way because it works. When the impact of issues is low, and the cost to fix them is low, the rapid feedback loop of agile development is extremely effective. The benefits outweigh the drawbacks. It's a no brainer
1 reply
0 recast
0 reaction
Alex Roan
@alexroan
Consider Hardware. Developing Hardware is a very different experience. There’s no rapid feedback loop or moving fast and breaking things. When something goes wrong, the impact is NOT low. Phones combust in pockets. Planes go down. Rockets blow up.
1 reply
0 recast
0 reaction
Alex Roan
@alexroan
How do these issues get fixed? Total recall, or sometimes, they just don’t. Impact: High, Cost to fix: High. The process of idea to execution of a new piece of hardware looks nothing like the process of moving fast and breaking things.
1 reply
0 recast
0 reaction
Alex Roan
@alexroan
Every minute detail is mapped out and thought about way ahead of time. The testing/QA process is rigorous and grueling. There is no fallback. It needs to be right the first time. When you think about Smart Contracts, which of these two buckets do they naturally fall into?
1 reply
0 recast
0 reaction
Alex Roan
@alexroan
In Web3, when a Smart Contract has an issue, the impact is not just a disgruntled user, it’s often millions and, in some cases, billions of dollars.
1 reply
0 recast
0 reaction
