An engineer at SquareSpace once referred to his company as "an overnight success, 7-years in the making." This cheeky insight pays homage to the marathon of work that is often required when building a successful product and / or business. Which begs the question: when is it appropriate to start thinking about scale? Should you be taking it into account during early ideation and the construction of your MVP (Minimum Viable Product)? Or, should you kick the can down the road with the assumption that you can always throw money at the problem later (either by hiring smart people or by vertically scaling your existing compute resources)?
This week, the crew talks about our experience in scaling web application systems; what we have - and haven't yet - had the need to consider; and, how we calculate the return on investment (ROI) when it comes to adding complexity to a potential solution ("innovation tokens", anyone?).
If you like this episode about scaling, you may also enjoy our previous episode on Monoliths vs. Microservices.
Listen to Episode 010, with:
- Adam Tuttle → Website, Twitter, LinkedIn
- Carol Weiler → Twitter, LinkedIn
- Tim Cunningham → Twitter, LinkedIn
- Ben Nadel (that's me) → Website, Twitter, LinkedIn
Triumphs & Failures
Adam's Triumph - After switching to a new platform, his ORM (Object-Relational Mapping) code stopped working for "reasons". And, instead of spending a whole week trying to figure it out, he just spent a single day replacing the problematic ORM queries with native SQL statements. This was a veritable "Master Class" in pragmatic problem solving.
Ben's Failure / Triumph (that's me) - This week has been kicking my butt! I'm exhausted and stressed out - even my feet hurt. This is due, primarily, to the HTML emails that I've been crafting at work. That said, I've been able to take my "failure" and transform it into a "triumph" by channeling that frustration into an exciting new approach for building HTML emails that's powered by ColdFusion Custom Tags. It's still early, but I'm hella stoked on the concept!
Carol's Triumph - She wrote some rather complicated code that dealt with edge-cases in her application that weren't really ever going to happen. And, when her teammates discussed this with her, she did the honorable thing and removed her code, leaving in its place a much simpler solution. The real triumph here is that she was able to overcome the "sunk cost fallacy" we engineers often succumb to when having to confront the questionable value of our own solutions.
Tim's Failure - What started out as a thrilling exploration of Redis has turned into a battle for sanity! For reasons that he has not yet been able to understand, the data that he's been writing to a Redis cache isn't always available for immediate read. This is in his local development environment and he's the only one hitting the code. It just doesn't make any sense!