Seven Minutes of Hell and the Last Mile Phenomenon
By Sam Boochever, co-founder of 1Degree
In the tech world, the “last mile phenomenon” — a phrase derived from the telecom industry where the last mile was the final leg of the connection to each home — refers to the disproportionate time and effort needed to solve the final piece of the puzzle, which is also usually the most important. Last March, as my business school classmates were headed off to various exotic locations for some R&R, I was headed to LA to work side by side with our CTO and try to solve 1Degree’s last mile problem. Our issue was that the video chat connection, the meat and potatoes of our product, was only connecting intermittently.
Thomas Edison famously said, “I have not failed. I have just found 10,000 ways that won’t work.” Coding certainly falls into that trial and error paradigm. You identify the outcome, develop a plan of action, and then keep trying until you get it right. As I left for LA, it felt as if we had discovered about 9,000 ways in which the video connection didn’t work reliably. The real problem was that we couldn’t identify the root of the problem. Sometimes, the video connected and, when it did, it worked perfectly. Yet, other times, running the same test, the video wouldn’t connect. We couldn’t isolate the source of the unreliability. Worse, based on our workflow design, every test took an excruciating seven minutes to run.
With the first iteration of 1Degree, User A created an auction consisting of back-to-back two-minute chats. Upon creating an auction, User A would be placed into a waiting room the lasted for seven minutes. This waiting room exists so that all of User A’s followers, who received a push notification alerting them of the live auction, would have sufficient time to bid on User A’s auction. After seven minutes, the highest bidder would automatically be connected with User A in a private FaceTime chat.
As such, getting one small aspect of the auction process correct (i.e. the bid portal timer), which, like most coding, required extensive trial and error, could take an entire day, broken into seven minute cycles. We quickly dubbed this seven minute trial and error waiting period as the “Seven Minutes of Hell.” The video chat connection, the last and most important piece of the puzzle, was proving disproportionately difficult to solve.
Hours turned into days and days were quickly turning into weeks. We were in trial and error purgatory, seven minutes at a time. We would spend large parts of entire days just watching and waiting, staring at multiple phones as they counted down to zero hoping that this time would be different, that somehow, this time we had discovered the solution. The cycle was brutal; each time we tweaked the code, our spirits would buoy as we watched the countdown timers, only to have our spirits crushed seven minutes later. If the video chat did connect, as it sometimes did, it only heightened our optimism and our subsequent malaise, when the video failed to connect a few tests later. The tensions were palpable. Our interactions were curt. Internally, we all started to wonder if we would ever be able to bring our product to market.
Turns out, to solve the problem, all we needed was a change of scenery. The coffee shop we usually work out of had recently changed its closing time from 11pm to 8pm. After another frustrating day in the Seven Minutes of Hell cycle, we got kicked out of our normal workspace. Instead of calling it a day, we decided to go across the street to the Starbucks to keep testing for a few more hours with waning hope of solving the connection problem on this day.
Our first test at Starbucks was successful. So was the second. And the third. After four successful tests in a row, we started to become optimistic. An hour later, after eight consecutive successful tests, we were confident we had won the game of trial and error. However, we realized we hadn’t actually made any changes to the codebase before we transitioned coffee shops. The only change was the internet. By sheer luck, we had identified the problem.
We realized that as customers had come and gone from our usual coffee shop throughout the day, the speed of the internet would vary. We didn’t identify the unreliability of our video chat connection as an internet problem because, more often than not, the chat would connect and the quality would be great. It didn’t even occur to us that varying internet bandwidth in the coffee shop could have been the issue. Once the problem was identified, the solution was straightforward. Luckily, at such a late evening hour, the Starbucks in which we made this discovery wasn’t very crowded — our cheering and high fives didn’t disturb many customers. After identifying the issue, we soon put in a governor that tested the device’s connection speed before allowing the device to create or bid on an auction and then, relieved and excited, submitted 1Degree 2.0 to the app store.
Months later, worrying about the reliability of our video chat connection feels like a far-off memory, since we’ve had no issues after that important day. As I reflect on the days of the Seven Minutes of Hell, I barely remember the grief and despair. I only remember the feeling of accomplishment when we solved the problem. It seems as though the victories always erase the feelings of 10,000 (trial and error) failures along the way. After the Seven Minutes of Hell, I try to take failure as a positive. After all, if it were easy, someone else would have already done it.
