Talks

Summarized using AI

The Life and Death of a Rails App

Olivier Lacan • April 17, 2018 • Pittsburgh, PA

The video titled 'The Life and Death of a Rails App' by Olivier Lacan, presented at RailsConf 2018, discusses the evolution and lifecycle of Rails applications, particularly focusing on the experience of Code School. It underlines the challenges faced by companies that start with great enthusiasm and innovation but may struggle with aging software, rising complexity, and maintenance over time.

Key points include:

  • Inevitability of mortality: Every web application will eventually become obsolete, similar to how humans face mortality. The speaker emphasizes that websites can encounter issues such as 404 errors as time goes on.

  • Roots in collaboration: Lacan frames the emergence of Code School through a collaborative effort, emphasizing that many good ideas in software arise from community engagement and shared learning experiences.

  • Growth challenges: As Code School evolved, it faced challenges like increased complexity, technical debt, and scaling operations while trying to maintain a coherent developer experience.

  • Opportunity costs: The talk highlights how cost-saving decisions, such as moving away from cloud services like Heroku to self-hosting, led to unexpected complications and ultimately hindered productivity.

  • Balancing innovation with practicality: There is a discussion about the allure of creating custom tools versus utilizing standard solutions, emphasizing that many teams often feel they are unique but share common challenges with others.

  • People vs. code: Lacan shares insights about prioritizing people over code, acknowledging that maintaining a supportive team culture is crucial for a project’s success.

  • Preparing for failure: The narrative culminates in the shutdown of Code School, provoking reflection on the emotional aspects of closing a chapter and transitioning within the tech industry, particularly concerning legacy apps.

  • Final considerations: He concludes with an emphasis on nurturing talent, promoting a culture of kindness, and recognizing the contributions of colleagues and users, rather than solely valuing the product. This approach can foster a resilient community in the face of inevitable changes and challenges.

Overall, the talk is a poignant reminder of the transient nature of technology and the importance of focusing on community and collaboration, culminating in the assertion that while products may perish, the relationships built and the lessons learned endure.

The Life and Death of a Rails App
Olivier Lacan • April 17, 2018 • Pittsburgh, PA

RailsConf 2018: The Life and Death of a Rails App by Olivier Lacan

Now that it has become a mature web development framework, Rails is no longer the exclusive realm of burgeoning startups. Healthy small and large businesses have grown with Rails for years. Shrinking and dying companies too. In this talk we'll look at how Rails and its ecosystem of libraries and services can support both newborn and aging apps, and when it struggles to do so.

RailsConf 2018

00:00:11.240 So, who has met me before? There's a few people here. If you're expecting cheery stuff and fun, goofy jokes, as you can see from the title, it's possible that this talk is going to be a little less light-hearted than usual. This is also why I'm dressed like this; I would never impose this on you ever again.
00:00:29.070 This is a serious topic, and it's the first time I'm discussing something like this at a conference this big, with a room this wide, which is going to be interesting. It's also the first time I’m telling this story in this way, so if it's a bit messy, that's normal; life is messy, and death is also messy.
00:00:41.399 So just roll with it if you can. You can laugh at me if you want, you can cry with me if you want; it doesn't really matter. I really recommend you to go see Ernie Miller's talk after this; it’s a perfect sequel and it's going to be much more upbeat than mine. So, let’s get started.
00:01:08.159 Since I indicated that it would be a light-hearted talk, I'm going to start by saying something a little heavier: we are all going to die, without exception. There you go.
00:01:29.250 Our websites are going to 404, and we will probably tell our friends. We might try to see if our old websites are still alive somewhere in the Wayback Machine, but a lot of those links are going to be dead. This is what we do: we make things that disappear quickly, and then we also disappear quickly. Thanks; this is me, usually I’m more cheery.
00:01:54.509 I work for a company called Code School, and I've been doing that for the last six years now. This company was acquired by Pluralsight in 2015, and we do a lot of the same things. We're basically trying to infuse Pluralsight with the elements that made Code School special for so many years.
00:02:19.049 I’m going to tell you the story of Code School, or any app, website, startup, or company that you've been a part of; it's not particularly special, it's just one of many stories. But I'm going to attempt to glean some useful knowledge and wisdom from our little story.
00:02:30.989 Back in late 2010, in Orlando, Florida, someone did this, a common occurrence that millions of people have experienced. Realistically, it’s probably more accurate to depict it a bit differently; the bottom part is wishful thinking. It was actually my friend Andrew Smith, who I went to school with and at the time worked for NV Labs in Florida.
00:03:07.560 They had been working on this idea because they attended numerous conferences and workshops, where they had to organize many Rails workshops. The process was confusing, messy, and people wouldn’t be in sync; oftentimes, they wouldn’t have the correct dependencies installed. So, they decided to create something called 'Rails for Zombies,' which would simplify that process.
00:03:18.419 This was the first commit to turning 'Rails for Zombies' into its own product. It was something that could be taught on multiple platforms, not just Rails itself. As is customary when you create a Rails app, you spend a few days changing the defaults and installing the specific tools you prefer, like RSpec, Factory Girl, Factory Bot, and Tapas Bar.
00:03:30.599 You noticed some people starting to join in on the fun. By December, they were really excited and worked even through the Christmas break to get it done. The actual first commit occurred on December 22nd, 2010. I joined this story exactly one year later, in January 2012, after trying everything I could to get into this adventure.
00:04:02.639 At the time, I was in school, and I could see there was something special happening. The site looked like this: if you've been to Code School, you know how it had a very textured design, with lots of cool royalty-free art that looked fancy, coupled with various interactive buttons and calls to action. Initially, we only taught a few subjects, perhaps just four or five courses. It was a tough sale to pitch subscriptions against that backdrop.
00:04:48.870 The very first thing I did was nitpick; there was a button that wasn’t clear enough for team subscriptions. That was the first thing I touched in the codebase three days after starting my job. Fast forward two years later, I was a bit more comfortable and much less concerned about impressing others.
00:05:14.790 Earlier, I think DHH talked about barriers to entry in the community. We were really concerned about bringing people into the Rails community, as it had so many advantages and benefits. During that time, 'Rails for Zombies' was this platform that eliminated the need to install Ruby or deal with any dependencies. Users could just start experimenting with Ruby and Rails, understanding how the interface and APIs worked.
00:05:41.900 It didn’t teach everything, but it helped users get started quickly. We also revamped the 'Try Ruby' website, which had become somewhat abandoned, making it more engaging and secure. The timing was right; browsers could handle the features we implemented, and other companies also joined in to teach people this way.
00:06:14.190 We spent an inordinate amount of time crafting quality content. Just like magicians performing tricks that bewilder the audience, we put a lot of effort into making our courses the best. The audience responded — people like you wanted to invest in our success and share their learning experiences with us, contributing to our growth.
00:07:00.120 In a few months after I joined, we revamped the website and added numerous courses for JavaScript, Node.js, iOS, and many other technologies. As someone who worked on the website, code school dot com became widely recognized — when people started their pet projects today, they were familiar with deploys on Heroku.
00:07:35.750 It was a fantastic, fulfilling time. However, there was also this aspect where we didn't notice as we were growing expenses creeping up, leading to monthly costs in the hundreds, sometimes even thousands. Occasionally, we’d have spikes in traffic whenever we released a new course, energizing the team.
00:08:12.330 We got excited about building this thing because we saw the positive response from users. We started adding gems and new features, and the project started becoming bloated. Aside from software dependencies, we began seeing human dependencies grow as well.
00:08:47.880 The team expanded, and people were relying on us to teach in their companies and schools. This was a time when we weren’t quite responsible enough to manage all of this on our shoulders. Adjusting to this growth took time.
00:09:18.350 During this time, we frequently questioned whether we needed to continue paying Heroku for hosting or if we could manage it ourselves. The naive belief of 'what could possibly go wrong?' often led to miscalculations.
00:09:45.270 Over the years, it took us considerable time to return to that earlier developer experience on Heroku. There’s this economic concept called opportunity cost; it’s the loss of potential gain when choosing one alternative over another. If you allocate funds to one choice, who knows what you'll lose on the other end?
00:10:10.930 This predicament only compounded when we noted how other successful peers in the community had convenient tools or customized solutions. It sparked ideas in us. We thought about creating our own tools to cater to our specific needs, believing that our unique setup would require it.
00:10:35.370 But the truth is, most of us are not that special. Sure, the product we create can be unique, but we all still face the same fundamental challenges: managing users, authorizations, billing, server configurations, and handling security.
00:11:00.150 We often built small tools to improve various aspects of our applications, conducting experiments with frameworks like Phoenix or Node. Before we knew it, we were managing over a hundred Ruby repositories for a team that never grew beyond fifty people.
00:11:26.440 We were producing more repositories than we had people. The desire to be unique drove us to develop solutions specifically for our niche, spending energy that could have been used on more standardized tools.
00:11:47.740 As David discussed this morning, we often felt that the built-in tools weren't special enough for us. We justified our choices based on a so-called quest for uniqueness while neglecting the value of adapting existing solutions.
00:12:09.980 This extended to newer frameworks emerging that competed with Rails, which were great for experimentation. The challenge was creating a false dichotomy where we saw Rails on one side and freedom, simplicity, or novelty on the other.
00:12:31.460 What we missed there was that we shouldn't have viewed it that way—especially as a small company with no investors. However, many good ideas existed within those alternatives, and many communities were eager to share these concepts.
00:13:02.420 And once in a while, those ideas would surface and become part of Rails itself. Think of Ruby as this vast arena of possibilities where useful techniques from various areas made their way into standard practices, benefiting everyone involved.
00:13:25.250 In 2010, significant conversations centered around where to place business logic, whether it belonged in Ruby’s core or within the Rails domain. We found ourselves caught in the chaos of choosing how to organize our work.
00:14:05.100 Everyone was discussing architectures like Service-Oriented Architecture (SOA) fiercely. At the time, we were eager to be thoughtful and responsible as our company matured.
00:14:36.600 Some senior team members decided to embrace this paradigm, considering it might give us clean, well-defined boundaries while still encapsulating business logic within manageable services.
00:15:07.650 Ultimately, opting for a distributed service architecture led to trading local complexity—something we understood—for the potential chaos of inconsistencies across multiple services.
00:15:38.530 Instead, we simplified; we kept operations centralized within one monolith that was service-oriented in nature. It made sense because it mechanically allowed us to create users, subscribe them, and charge for services effectively.
00:16:03.520 However, things became complicated when someone needed to charge a subscription without performing all the other linked actions we'd not foreseen, resulting in breakdowns.
00:16:29.230 This tug-of-war between functionality and service structures revealed that as long as we used Rails, we were stuck with its persistent models. Despite efforts to use 'service' abstractions, it often felt like just adding a decorative mustache to the existing Rails functionality.
00:16:51.270 With this realization, service definitions began to shift. We retained some of those 'Rails' approaches while attempting to adapt to new ideas, yet somewhere along the way we lost track of the balance.
00:17:15.490 The project that took off from a conference began morphing into a product upon which people became increasingly dependent, so we had to take all these considerations seriously.
00:17:42.120 Performance, reliability, and the unfortunate term 'doctor's excuse' seldom sufficed for justifying haphazard decisions, especially as we began feeling accountable to our customers.
00:18:05.360 However, the cycle of instability persisted. People entered and exited roles whimsically, resulting in a lack of ownership over our products. The instability was palpable, leading to inadequate knowledge of how everything integrated.
00:18:31.290 During this period, Katie and Joel joined our team. We recognized the importance of building our team responsibly, pairing individuals with varied backgrounds to cultivate our project's future.
00:18:56.570 Their collaboration—the combination of technical proficiency and liberal arts thinking—proved invaluable in our discussions. They allowed us to look deeper into our processes and vocabulary.
00:19:22.330 As the team diversified, we felt compelled to foster an environment where all voices could matter, allowing for constructive feedback and discussion without fear of punishment.
00:19:46.560 As the company matured, we began to institutionalize our processes, inadvertently stifling the excitement and spontaneity that fueled our earlier success. We introduced rigid frameworks around production, which led to less enthusiasm.
00:20:09.180 A quote often attributed to Mark Twain says that during a gold rush, it's a good time to be in the pick-and-shovel business. As we took stock, we noticed that we had accumulated an abundance of tools and resources.
00:20:35.610 This fertile ground led to a surge of companies filling the gaps we hadn’t realized existed. But for us, the trappings of excessive creation became problematic; our ability to objectively assess our output came into question.
00:20:58.140 We became focused on scalability—more people were using our platform at different times across the world. Our website began faltering under heavy spikes while we ignored necessary upgrades.
00:21:26.800 This led us to seek assistance from those in the community who were more seasoned than we were. Performance became a critical area of concern.
00:21:54.570 We eventually reconciled the reality that Rails could scale. However, we overlooked browser performance challenges, believing those weren’t our problems but rather issues for JavaScript developers.
00:22:29.650 We found ourselves spending excessive time scratching our heads over graphs when we should have been focusing on solid, clean code.
00:23:05.380 Moreover, as a company, we learned to value the people over the code. The people owned the products, the services, and were the keys to success.
00:23:25.830 Where coding once dominated my focus, I've shifted towards removing old lines of code—bulldozing outdated practices to make way for newer ideas to flourish.
00:23:49.170 As we reached a substantial scale, security became a pressing concern. The risks involved with who had access to sensitive information grew with our team size.
00:24:12.370 We retained old habits from a scrappy startup phase, leading to insecure data practices. I recall a particularly embarrassing note: many old passwords were stored in plain sight, leading to a moment of panic.
00:24:39.600 Eventually, we started receiving communications from ethical hackers who discovered vulnerabilities. Their feedback, albeit sometimes alarming, was essential.
00:25:04.910 Just as a town may overlook subtle issues until disaster strikes, companies can lapse into a false sense of security, only to find themselves in difficult situations.
00:25:23.800 Privacy regulations, like GDPR, introduced challenges that required immediate attention. We began noticing significant implications, particularly relating to user data management.
00:25:41.360 Identifying sensitive personally identifiable information (PII) became paramount as we recognized that certain data, such as IP addresses, lay within our reach as we collected records over the years.
00:25:58.930 As our compliance obligations grew and became prohibitive, we faced new responsibilities we hadn’t fully anticipated, leading us to acknowledge the intricacies involved.
00:26:16.480 About three years prior, Pluralsight acquired Code School, and during that time, our focus shifted toward integrating the best of what we had created into their platform.
00:26:34.340 Now, though the journey has led to changes, we are faced with bittersweet news: as of June 1, 2018, Code School will be shutting down.
00:26:53.300 That reality fills me with sadness; the term 'sunset' feels more like a euphemism for a demise, where we shroud an ending within polished phrases.
00:27:08.870 In stark honesty, we need to recognize that saying 'we are shutting down Code School' is a painful truth—one that reflects the hard work and dedication poured into building something supportive and valuable.
00:27:27.830 While the spirit and interactive core of Code School will continue in some form within Pluralsight, the transition cannot erase the hard-fought history we have built.
00:27:41.320 However, as I look back on this experience, I realize there is far more to celebrate. It’s not solely about the legacy of a product but the team I've grown alongside and the community of learners we created together.
00:28:09.710 Though the endeavor that consumed an estimated 20% of my adult life is concluding, I want to ensure that this journey informs the future rather than defining it.
00:28:30.050 This is a moment of reflection on how to better navigate the complexities we face, reminding ourselves that we must prioritize our values over mere functionalities.
00:28:43.910 Wrestling with challenges should never impede the kind of culture we want to uphold, one built around empathy, understanding, and integrity.
00:29:02.320 Lessons exist all around us—in the triumphs and failures alike. Encouraging one another, fostering a sense of community, and celebrating even the tiniest victories makes all the difference.
00:29:13.970 This journey, rife with moments of joy and chaos, perfectly encapsulates the essence of learning by doing and supporting each other along the way. Thank you very much.
Explore all talks recorded at RailsConf 2018
+94