Platform Calgary’s Digital Ribbon Cutting.
Platform Calgary’s Digital Ribbon Cutting.
The importance of ideas, experimentation and being open to failure.
“Just fake it.”
I had heard these exact three words from several individuals over the last 24 hours. My wife. My boss. Friends. Colleagues.
In a way it was terrific so many different people in my life came to the exact same conclusion. It meant that I was doing a very good job explaining my problem.
It was May 30th, and Platform Calgary was opening its doors in two days with a widely anticipated public ceremony that I had put myself right in the middle of. I promised to deliver a digital ribbon cutting ceremony where attendees would pull out their phones, scan a QR code, get a button on their screen, and mash it collectively with a thousand other attendees to move digital scissors across a digital ribbon and cut it.
The problem? I had volunteered to build this out from start to finish just days before with the understanding there would be exponentially fewer attendees.
“Hey, that’d be fun. If it’s digital we could make it interactive so everyone could take part” was my first reaction when we were asked what we could do for our friends at Platform. “Let’s have them all cut the ribbon with their phones”. I committed to exploring the idea and got building.
Three web pages was all it would take:
The page to be displayed at the venue, first showing a QR code for participants and then once things begin, the ribbon cutting itself.
The page the QR code takes participants to, that has the button to press.
The page an admin would use to activate everyone’s buttons so no one could begin cutting ahead of time.
Socket.IO would connect everyone’s buttons to an Express.js server that keeps track of the “cuts” (button presses by participants), translating them into progress on the scissor cutting animation.
I got a functioning prototype up later that day. The team loved it, and we committed to running the ribbon cutting. We had several days ahead of us for the creative team to supply real assets and for me to do a little more polish. Easy.
Of course one of the most common mistakes developers make is saying how easy something is to do. We live in an amazing world with so many technologies freely available to use that it’s hard not to feel masterful gluing them into a concept quickly.
But while getting something working on your screen is easy, the veterans know the real work comes making sure it works for everyone else.
We toured the Platform Calgary space ahead of time to do a dry run of the set up for opening day. We toured the main presentation area, the office spaces, and finally a large hall with more displays. “This will be the event overflow area” I was told. Overflow? My spidey-sense tingled.
“How many guests are we expecting?” I replied.
“1,000? 1,500? There’s also a nearby conference that day so we may pick up a few hundred others.”
Huh.
My original testing plan when I thought the event was for 100 people was that I didn’t need to do formal load testing at at all. 100 simultaneous connections for this technology stack — even if they’re all mashing buttons and sending tons of messages in parallel — didn’t strike me as something to be concerned about. But for fun I’d probably loop in whoever was in our office that day to help test it, mostly for my own satisfaction of watching the thing work and seeing people’s reactions in real life. The ribbon cutting experience was fun after all.
My new testing plan was to get serious. I brought in Artillery as it appeared geared to writing tests for Socket.IO implementations, and I wrote a testing scenario to have some simulated users connect, wait, press the button a bunch of times and jump off.
100 users worked, no sweat. My intuition was right. 200. 300. 400. 500. Half way there!
At 800 it started to buckle. Messages were dropping — meaning button presses from users were not always being received by the system. This resulted in an exceptionally embarrassing way for the experience to fail — it wouldn’t crash in some showy failure everyone would recognize as such. It would stall out. The pair of scissors would be pushed along and then come to a confusing halt.
Testing 1,000 users was even worse; 1,500, my stretch goal to feel truly safe, wasn’t even worth testing at all.
So I did something I seldom do but should do a lot more of. I logged off the computer and walked away. What had I gotten myself into?
Opening day, June 1st, was just two days away and I had a concept that wasn’t working at the scale it needed to. Just fake it. Activate everyone’s button so they could mash away, but have the display show a scissors cutting animation decoupled from any actual button presses. No one would notice. No chance for failure.
After all, that’s the kind of pragmatic approach I encourage for the teams I work with: time is limited and budgets are tight, so focus on the areas that matter and dial in the areas that aren’t impactful.
But it felt like a betrayal. We were opening Platform Calgary, a brand new technology hub for the city to help startups ideate and grow. Project success was not to ensure a flawless ribbon cutting, it was to try something new and bring the community along for the ride. Being good, not perfect. Trying and failing instead of not trying at all.
Or at least, that became my justification for ignoring the advice of everyone around me and doing it for real.
I managed to keep my day mostly computer-free. I had meetings. I had a lunch one-on-one. The chats where everyone told me to fake it.
That night, I took a last stab at the code.
There was no getting past the fact 1,000 people averaging 8 presses on their phone (8 being number of presses per connected user I coded in so the experience wouldn’t be instantly over) would create a burst of 18,000 messages to process in just a second or two. All I could do was look through my code and see if I was doing something dumb that made it worse. I was.
Button presses were accidentally being sent to every connected user instead of just the ribbon display. Fixed.
The ribbon display was unnecessarily updating its progress back to every connected user. Fixed.
Progress to the ribbon display was sent out with every press rather than when enough presses accumulated to actually move the scissors a pixel on the display. Fixed.
I ran a test at 1,200 users. It worked. 1,500! 1,600! The ribbon cutting is going to happen.
Opening day. I met with Terry Rock, CEO of Platform Calgary and MC of the event and walked him through the ribbon cutting. I was feeling confident, but my testing was simulated and real world conditions are never quite the same. I had to let Terry know how things could go wrong so he’d have that outcome prepared for.
“It’s real. If things go wrong it will stall out. Are you okay with that?”
“That’d be fun!” Terry replied.
He knew like I did, none of this was about being perfect, it was about trying something and being honest and authentic about it.
The calm that exchange brought me was brief. The crowd was piling in. There was a line around the block to enter. Provincial MLAs and City Councillors took their seats. I had opened myself up to public failure, and I told myself it would be fine, but now I really just needed this damn thing to work.
It did.
It was a hugely attended event as promised, but one thing I forgot to factor into my calculations was engagement rate. Of the large crowd, only 177 people loaded up the experience to mash their phones. Ironically, my lazily-tested and poorly-written first iteration of code would’ve handled that no sweat. It turns out nothing was ever going to be a problem. Because of course.
So if there’s any thing to take away from this story, it’s this:
Validate your requirements. I should not have been operating under the assumption this event would have a fraction of the attendees it had.
Don’t assume most of the work is done once you’ve built a working concept. The work has just begun.
Define what success looks like for your project. Failure might not only be well within the parameters, it might be encouraged.
Experiment and try things.
And don’t be so stubborn as to avoid an easier solution to your problem. Even if it involves faking it.
But what would be the fun in that?