It’s July 5th, I’m on the phone with Tony Sebion, a Director at Omni and the company idea guy, and I have no idea what Solidity is or how a Smart Contract really works. The conversation was lengthy and detailed but the gist was this: Tony drafted Kevin Brey and myself to build his social object/technical proof-of-concept for That Conference - an Ethereum blockchain-based betting application with a commercial music streaming device, smart contracts to broker the game, and a mobile-friendly app for users to register, place bets, watch the game, and win cryptocurrency. Simple, right? Yeah, right. It’s a month before our go date and I don’t understand half of the words in my description.
Building software isn’t trivial, really ever. Now consider the month deadline with zero code, zero user stories, zero understanding of the Solidity language, EVM (Ethereum Virtual Machine) environment, development tools, etc. coupled with a crude understanding of how tech’s ultimate buzzword - blockchain - even works. At one point I think I muted the call and laughed out loud to myself (sorry, Tony, you rock), because there was hardly a path in my mind that brought us to a successful launch. But somehow, we found a way.
Somewhere on this page should be an architectural diagram, so I’m going to just gloss over the details, but basically there are a few things we had to build before we could even see if our product idea was possible. Big thanks to Microsoft for putting out a BaaS (Blockchain as a Service) template for Azure that we leveraged heavily to run our private network for the game. That’s right, no real ether exchanged here. After the network was running and we roughly understood why and how, we wrote the first iteration of the Wager contract, or the code that brokered our game on the blockchain. The first pass was a nightmare, and Kevin and I had to spend a bunch of time talking time/space complexities in order to re-write the entire thing from scratch. Basically, the code was so inefficient that the entire game would grind to a halt after 15 or so rounds. Not great considering the 500-600 estimated rounds throughout the conference.
Once we were able to take off our big-O hats and get back to programming in abstractions, we had to build a service to write the currently playing song, on song change, to our contract so that we knew when to pay out correct bets. This was pretty straightforward, and Kevin did a great job building this out to the nines which you can check out here. This was a simple Node.js app running as a systemd service on a Raspberry Pi 3.
So, on the Friday before the conference we packed everything up and prepared for the worst. Of course someone would break it, I thought. Of course the network will fall off midway through. Of course this thing won’t scale to 100+ users. Again, it did, well kind of. We had a few curious peers poke holes in the network and on two occasions the network did drop completely. Oops!
Ultimately, though, the thing worked, our power users seemed to enjoy it, crypto-anarchist types found it interesting and wanted to talk about the tech. In a four-week development cycle, certainly there are things we would have liked to have cleaned up, optimized, secured, and prettied up, but I think we did the most with what we had - two devs with very little knowledge on the tech and a bunch of hard work. I’d do it again in a second. Congratulations to our grand prize winner, and a sincere thank you to everyone who hung out with us at the booth to talk about 70s Rock music, the game itself, crypto-currency, Bitcoin fork drama, and whatever else happened in that crazy weekend. But a special thank to Tony Sebion, who just makes things happen, and could probably talk me into some crazy professional decisions if given enough time in a conference room, and Kevin Brey, who is an insanely clever and talented developer who made this happen as much as anyone else. Check out future posts on more specific aspects of our Blockchain Consultancy, Rockchain technical details, Smart Contract development, and whatever else I feel inclined to ramble about.
3 Ways to Compare Waterfall and Agile Software Development Methodologies