Hacking Development Culture: Treating Developers As People

Talks

Austin Fonacier

#test-driven-development

#rails-upgrades

#service-objects

Hacking Development Culture: Treating Developers As People

by Austin Fonacier

The video titled 'Hacking Development Culture: Treating Developers As People' features Austin Fonacier, who shares his experiences as the lead software architect at Spokeo. Fonacier's talk focuses on the evolution of the development culture at Spokeo, which transitioned from a chaotic environment dominated by technical debt to a more structured and quality-driven approach. This transformation occurred against the backdrop of a company that initially operated on a Ruby on Rails 1 codebase and later upgraded to Rails 3 without a complete rewrite due to the fast-paced nature of startup demands.

Key points discussed include:

Initial Challenges: Fonacier describes the difficulties faced when he joined Spokeo, including a high level of technical debt and a culture where developers often worked in isolation, focusing purely on meeting QA standards rather than fostering collaboration or code quality.
Communication and Upgrading: He emphasizes the role of effective communication, highlighting how senior developers advocated for the upgrade to Rails 3 by stressing its necessity for long-term sustainability and security.
Addressing Technical Debt: Fonacier explains how he tackled technical debt as he undertook a feature task, dedicating time to rewrite and streamline outdated code, improving testability and performance in the process.
Implementation of New Practices: The adoption of service objects to enhance code organization, coupled with a new emphasis on peer code reviews, greatly improved the coding standard and reduced bugs.
Cultural Shift: The gradual changes in development practices nurtured a more supportive environment where developers felt invested in their work, ultimately leading to better product quality and a more enjoyable workplace.
Management's Role: He advocates for managers to invest in their engineers, treating them as valued contributors rather than mere resources, which fosters greater engagement and productivity.

In conclusion, Fonacier reflects on the importance of navigating challenges within organizations and the necessity of promoting a developer-centric culture that prioritizes collaboration and quality over merely meeting immediate demands. He encourages treating engineers with respect and autonomy, noting that such investment benefits both individuals and the company as a whole.

00:00:00.089 Oh, thanks, Kobe. I am really happy to be here, and it has been a really great conference. Today, I'm talking about development culture. My name is Austin Fonacier. Last time I was here, I gave a small talk about my cat, who I still have. I am also the lead software architect at Spokeo, which is located in Pasadena. And here is my Twitter handle.

00:00:27.570 Every time I give a talk, I like to share a small personal story to break up the day. These are my two dogs. On the right, the black one is named after Cooper from 'The Amazing World of Gumball,' and on the left is Hank from 'King of the Hill.' The dog on the right is just your average loving dog, a bit dumb but very lovable. The dog on the left, Hank, is, by all accounts, a psychopath. One day, he was sitting on the couch, his back turned toward everyone, chewing on something hard. His brother, the dog on the right, was understandably curious, dying to know what Hank had. It was amusing to see that Hank was just chewing on something fake, trying to get a rise out of his brother. That's my story!

00:01:18.890 Now, let’s talk a bit about Spokeo. Please don't take this as a hiring spree for Spokeo; that's not what I mean. I’m trying to give you context about the development culture we have at Spokeo. We are a people search engine, and what you see on the screen is a search results page for 'Donald Draper.' For reference, this is used as an SEO page so that we can rank for 'Donald Draper.' Assuming you search for a name from a TV show, we want to rank highly for names in general. In terms of numbers, today, we deal with up to around 12 billion records, which I think is pretty impressive. Additionally, we manage around 18 million visits a month, so for all intents and purposes, we are considered a big data company and are relatively high-traffic.

00:02:58.310 Now, let's hop into a time machine back to 2006. This was the state of video games back then—who was excited about the Wii? I know I was! In 2006, we also said goodbye to the celebrity relationship with 'Lost,' and frankly, I'm still broken up about that. Back in 2006, the Rails 1 codebase was what we were working with at Spokeo. Hats off to those who’ve dealt with Rails 1 codebases! At that time, Spokeo was essentially a social media aggregator; you would enter your friends' email addresses, and periodically, the app would give you updates on what they were doing across various social media platforms.

00:04:08.160 Fast forward to 2010—let’s hop in that time machine again. Do you remember how the phones looked back then? Who here still has an iPhone 4? That's impressive! Also, we waved goodbye to 'Lost' at this time, and now, we need to go back and tell Damon to write a better ending! In 2010, Spokeo took a couple of pivots. Between 2006 and 2010, we upgraded from the Rails 1 codebase to Rails 2. However, we didn’t rewrite the entire codebase; we simply upgraded it. We transitioned from being a social media aggregator to being in the people search industry, which was a significant pivot.

00:05:10.740 Over time, our traffic grew exponentially due to those pivots, which is pretty standard for a growing company with increasing high traffic. The number of lines of code also increased dramatically over the years. Additionally, in 2010, I joined Spokeo—15 pounds lighter and with a full head of hair! I was completely astounded by the level of technical debt within the company. I don’t blame the founders since they wrote the code themselves, but being a bootstrapped company, they wanted to reach profitability as quickly as possible. They had to get to where they wanted to be in the fastest way, and I understand that.

00:06:25.000 When I first got hired, I was diving into a codebase filled with technical debt, which made me very close to calling for a job switch. I don't want to shy away from talking about the codebase's issues; I want to provide some reference points for where we were at that time compared to where we are now. One of my quotes for today is: 'Your unit tests are only as good as the team buying into and owning them.' I’ve been there, and I’ve seen the struggles. Every week or two, I was given a new feature to work on, and I could feel the isolation of writing tests for it myself.

00:08:35.399 I would be the only one writing tests, and if anything broke, I would often be left alone to handle it. It was frustrating because this development culture at the company meant we were just handed features to work on in isolation. We often found ourselves coding in a corner, and whether we passed QA really didn’t matter. After each sprint, I would look at the code and think, 'What is going on?' This culture led to a less than favorable coding environment and simple tasks often took longer than necessary.

00:10:12.000 At this point, while our company was growing with high traffic and relatively high revenue, the question was: how do you steer a ship that is moving when you're only one developer? Thankfully, I had two senior developers who voiced that they wanted to upgrade to Rails 3. To stand up to management, who constantly pushed for the next feature release, proved challenging. However, these developers were great communicators and presented many benefits of upgrading. They understood that while the upgrade might not directly increase conversions, it would significantly ease developer work.

00:12:13.299 One major benefit they highlighted was related to support. As developers transitioned to Rails 3, they noticed it was harder to find examples and solutions for Rails 2 compared to Rails 3. This inefficiency meant we were wasting time trying to solve the same issues repeatedly. Additionally, we often faced security vulnerabilities. The response was—we needed to upgrade to Rails 3 sooner rather than later to ensure we were not left behind on bug fixes. Furthermore, we were a profitable company wanting to attract talented engineers, but no one wanted to work with a Rails 2 codebase.

00:14:22.289 Ultimately, the project was approved, and the team began working hand-in-hand on regular projects and the Rails 3 upgrade. As the upgrade neared completion, they gradually shifted their focus away from regular tasks towards the upgrade. Moving forward, how do we go about setting these patterns and becoming a better team for it? One key way I’ve figured this out was by tackling technical debt. I took on a feature for the name SEO page that should have taken me a couple of days.

00:15:57.985 However, I decided to thoroughly address the technical debt built up over the years, taking about a week or two. The benefits included improved sustainability, testability, better performance, and a clearer understanding of the codebase. Documentation was crucial since, given the legacy code with various nested statement issues, it was essential to approach it at a granular level. For one of my quotes today, 'Deleting code feels good.' It gives you a refreshing feeling, much like a cold shower. Over time, we began to implement different service objects as well.

00:18:40.950 Initially, our controller actions were quite lengthy, with multiple lines. However, after reading design pattern books and engaging in discussions, we began creating service objects to handle different bits of logic. This drastically reduced the size of our controller actions and made testing simpler and the code more manageable. The goal was to make our controller actions cleaner while adequately documenting each part. This transition wasn’t simple and took time, but it was necessary for improving our coding structure.

00:20:26.160 Engaging with management was equally important as we considered the implementation of new patterns in our coding practices. I had meetings where I presented my ideas for enhancing the coding standards. While it was not perfect, team members bought into these changes as we explored extracting methods for better organization. Consequently, our team started working on reducing bugs and improving the robustness of our code. This shift was largely welcomed and led to noticeable improvements in our workflow.

00:22:38.460 As we established these new coding patterns, peer code reviewing became a standard part of our workflow. No longer did we have features going into the main branch without being vetted. This encouraged organic conversations about how we could code better and apply lessons learned. This slow change in culture has led to a higher percentage of test coverage, ultimately improving the developer’s experience and the product’s quality.

00:24:59.100 To all managers and future managers listening, I urge you to invest in your engineers. It’s the best decision; those engineers will appreciate it and invest back into you and the company. Avoid creating an environment where employees are mere machines soaking up resources; instead, treat them like grown-ups. Give them the autonomy to make decisions and avoid micromanagement. I will be posting the slides after this talk, even though they might not be filled with technical content. Thank you all so much for having me!

00:27:31.820 In conclusion, I navigated challenges both upward and downward in our organization. Convincing the CTO to accept my propositions was difficult, and recruiting non-Ruby developers proved challenging as well. However, as the company grew, I gained more freedom to instigate positive changes. If there are any questions, please feel free to ask. Thank you once again for your time!

LA RubyConf 2015