In Praise of Smallness

B.J. Allen

B.J. Allen

1 talk

#team-dynamics

#agile

#continuous-integration

#feedback-mechanisms

#rails-upgrades

#software-development

#technical-debt

In Praise of Smallness

by B.J. Allen

The video titled "In Praise of Smallness," presented by B.J. Allen at the Big Ruby 2014 conference, highlights the importance of focusing on small, manageable contributions within teams to achieve significant accomplishments. Allen discusses how big changes and systems within organizations often stem from a series of smaller decisions and actions. He emphasizes that while achieving big goals is necessary, understanding and valuing the small steps taken along the journey is crucial for sustained success.

Key points discussed include:

- The Nature of Growth: Organizations begin with small teams and ideas but tend to grow rapidly, which brings added complexities like enterprise governance.

- Feedback Culture: Drawing from experiences at TripCase, Allen underscores the necessity of frequent, low-stakes feedback to promote team learning and reduce stress. He compares project settings to education environments, advocating for regular, small feedback loops to prevent overwhelming scenarios akin to high-stakes exams.

- Agile Revival: The reformation of stand-up meetings at TripCase demonstrates how structured feedback and productive communication can enhance team dynamics. By implementing scorecards for meeting effectiveness, the team improved overall morale and performance.

- Incremental Upgrades: Allen shares lessons from managing the transition to more advanced Ruby versions, emphasizing that gradual changes prevent chaos during upgrades. He encourages breaking down large tasks into smaller, manageable steps to mitigate risk and ensure smoother progress.

- Deployment Practices: Highlighting the importance of distinguishing between deploying code and releasing it to users, he advocates for the use of feature toggles and frequent deployments to minimize anxiety and build confidence in team capabilities.

In conclusion, Allen asserts that embracing small, incremental changes can foster a productive working environment, lead to continuous improvement, and ultimately contribute to larger successes. He encourages engineers and teams to prioritize small wins to facilitate a culture of learning and flexibility, enhancing both individual and collective outcomes.

00:00:21.359 All right, thank you very much. I hope you guys are enjoying the conference as much as I am. I think the organizers, sponsors, other speakers, hackers, residents, and volunteers have all done a great job. The speakers, in particular, have really hit home; it’s almost as if many of them have been sitting in the meeting rooms that I'm in at my office, talking about rewriting our jobs processor and getting fed up with data warehousing and things like that. So, it’s a really great conference, and I'm really happy to be here.

00:01:00.320 So, that's the little dude that looks like me and lives in my house. He's about 14 months old and just started walking about two weeks ago. It's both very exciting and extremely terrifying all at the same time. He's a little dude trying to get big. This is a great moment, an exciting time for you and your team. It's a blank slate when you have a ton of big ideas in your head.

00:01:16.960 We have a lot of tools that help us get started quickly and move fast, with many small things happening very quickly and very few hurdles to overcome. Just as a reminder at this point in time, your test suite takes one and a half seconds to run. So, your team is moving fast, you're building small things, and you're building them quickly, which is really exciting.

00:02:04.159 But things start to change. You start getting more users, gaining more visibility, and securing more funding. You get more servers, and everything gets bigger and bigger. All of a sudden, things can become really overwhelming.

00:02:20.560 If you are in an enterprising company like the one I work in, you face a whole new level of business challenges. When I was trying to come up with this slide, I thought about the biggest, heaviest, and most cumbersome thing I could possibly put on it—enterprise governance. Enterprise governance is the kind of thing you could play a practical joke on another team that doesn't know you by simply going to one of their meetings, sitting in the back, and furiously taking notes. When they try to talk to you, just tell them you're from enterprise governance.

00:02:31.120 Not all of these things are bad; there is some good in everything on that screen. However, dealing with these big things can keep you up at night. A lot of times, I’ll wake up at 3 AM thinking about whether our background job processor can handle the load today, or if it’s time to start thinking about database sharding. All of those big things need to be thought about and dealt with. But there are also a lot of small things happening that we should celebrate and focus on.

00:03:01.679 My name is BJ Allen, and I have the privilege of working at Sabre just up the road. I work on an app called TripCase. TripCase is designed to help you take better trips, and I love that tagline because everyone wants to feel relaxed, in control, and informed when it comes to traveling. You want to be the person who gets a notification on your phone that your flight's gate has changed, and you stand up knowingly, looking back at all the people who don’t know what's going on, as you head off to your new gate.

00:04:29.199 I’ve been writing code for just under 10 years. Before that, I was a middle school and high school band director in Austin and Round Rock. I wish I had better photographers at the time. My undergraduate degree is in music education from the University of Texas at Austin. Thank you, Aggies.

00:04:55.760 This is a guy who had a big impact on the way I think about human behavior. This is Dr. Bob Duke, the director of the Center for Music Learning at the University of Texas at Austin. I remember one of the first classes I had with him in educational psychology. He drew this up on the board and said, "As teachers, it's our responsibility to set up an environment where feedback occurs at very frequent intervals and very low magnitude." He explained that the worst scenario would be having a college course with a midterm and a final, both worth 50% of your grade. This setup is quite stressful, creating a lot of anxiety.

00:05:21.680 Suppose you go through the course without any feedback for seven and a half weeks, then have to deal with the anxiety of the big midterm exam. If you barely pass, it only gets worse going into the final. At worst, if you fail the midterm, it’s too late to drop the class, and motivation is gone. Instead, we want a system where feedback happens at very frequent intervals, making each instance much lower in magnitude—much less anxiety and stress. That is how to set up a good learning environment.

00:06:05.680 The importance of feedback is well supported by research. My wife, who is the director of music education at SMU in Dallas, sent me a few studies. I'll be honest—I really only read the abstracts, but I pulled out some important findings. For example, students quizzed twice a month outperformed those quizzed less frequently in both short-term and long-term assessments. Low magnitude, low stakes quizzing, with opportunities for feedback occurring at frequent intervals, produces significant learning benefits.

00:06:58.639 We talk about feedback a lot in software development as well. I would like to discuss a few things from my experience with TripCase where this concept applies very appropriately. When I first started at TripCase, the teams were well underway in a big rewrite and redesign of all the client applications. The mobile app was being rewritten, and the desktop web application was mostly rewritten from scratch. While one could argue whether this was a good idea, it was where we were. The teams were agile, but by agile, I mean not very agile at all.

00:08:06.320 There were stand-ups, stories, iterations, and demos, but it lacked true agility. One of the teams wasn't even having a proper stand-up, and I went in to ask for a photo that looked like they were having one. What I received was less than inspiring. If you attended those stand-ups early on, you would have seen vague updates and a lot of mumbling. There was a pattern where contributors quickly went through their reports without meaningful input, and after the stand-up, everyone would rush back to their desks to start coding. The whole exercise felt pointless.

00:10:00.960 This behavior leads to an approval mistake; feedback was implicit. In this case, the 'feedback' communicated was to keep quiet, focus on individual tasks, and get back to coding. Unfortunately, this lack of communication hindered team dynamics, resulting in terrible story completion rates and low morale. Eventually, we hit a breaking point where we needed an agile revival. A lot of what we implemented worked, emphasizing correct, constructive feedback during stand-ups. As a team, we agreed on what a productive stand-up looked like.

00:11:00.320 At the end of stand-ups, we had a simple scorecard asking whether the session was good or not and why. This practice created a mechanism for giving feedback and addressing any shortcomings. While it might remind some of gold stars in elementary school, it served a purpose—it offered clear answers on the session's effectiveness. Providing constructive criticism within a professional setting is challenging due to the negative connotations associated with it, but negative feedback doesn’t have to carry only negative implications. It’s critical that negative feedback is accurate, contextually appropriate, and delivered without emotion.

00:12:44.560 Once we overcame this obstacle, communication improved significantly. Surprisingly, everything else began to align well, and general team satisfaction rose. I encourage you, whether you find value in stand-ups or not, to explore all the ways your teams communicate, be it through chat rooms, hangouts, or meetings. You should aim to give mindful feedback and embrace the necessity of negative feedback among colleagues.

00:14:08.440 When I joined TripCase, it was essentially a monolithic Rails application running on enterprise edition 1.8.7 and Rails 3.0—a version that the Gemfile indicated, but the actual code had numerous monkey-patched backports to mimic desired behavior. After determining that there had been significant turnover, it was evident that the pressure to immediately upgrade posed difficulties. As a result, we inherited a problematic codebase, and with the ongoing redesign, it was not the ideal time to address the underlying issues.

00:15:39.040 Upon completing the redesign, scheduled for January of 2013, we were eager to tackle necessary upgrades. Unfortunately, earlier that same month there was a security update, resulting in multiple follow-ups. One upgrade turned into another urgent situation without a clear path for progression, leading to chaos around an emergency fix—all occurring right before a conference.

00:16:57.760 The stress of an unexpected upgrade hit again with Ruby 1.8.7 reaching end-of-life status, forcing our team to scramble. We initially established a reliable protocol, creating branches, setting up CI builds for Ruby 1.9.3, and diligently fixing tests. Ultimately, the improvements paid off when we finally merged to Ruby 2.0, making it much easier, because the lesson we learned slowly came together: systemic improvements are the key to making upgrades manageable.

00:19:14.640 The experience taught us the importance of handling changes gradually, rather than attempting everything in massive cuts. We designed small improvements and consistently carried them over into the current base code. Smaller changes allowed us to mitigate the risk, keep momentum forward, and enjoy smoother existences of those applications. As a result, we proved our abilities, eventually running Ruby 2.0 in production.

00:20:58.720 The important takeaway here is to take upgrades seriously. Building a solid upgrade strategy is vital to avoid finding oneself pushed into a corner by sudden requirements for essential security updates, like many of us experienced early on at TripCase. Break large tasks into small incremental steps, keeping everything manageable and low stress. Deployment should be our most exciting moments as engineers; however, this requires proper planning.

00:21:48.560 Looking forward to releases should be a time of enthusiasm rather than dread. Lesser risk releases are essential; each step counts—incremental changes will help minimize tension on development teams. Regular and deliberate engagement will allow you to sharpen your deployment and release strategies. Don’t let your processes become stale or impractical, as it fundamentally impacts your functionality.

00:23:11.680 Moreover, it's advantageous to decouple deployments from releases. Deploying code is distinct from making it available to users; utilizing feature toggles provides flexibility to control which features are turned on or off. Collaborating on smaller changes enables teams to practice their skills effectively, ensuring readiness for unexpected moments.

00:24:48.560 Finally, remember the significance of practicing deployments often. Ensuring frequent, low-risk deployments fosters growth and confidence in your process, preventing anxious moments when delays occur. Your development environment can grow into an overwhelming sense of urgency with larger releases, but smaller, more frequent outputs help mitigate this feeling altogether.

00:26:57.760 In conclusion, I've shared experiences from TripCase to encourage you to maintain a focus on keeping things small and manageable. Acknowledging successful small changes will facilitate a productive environment, allow insights to surface more naturally, and promote a positive culture centered on consistent learning and improvement. Thank you for this opportunity to share my thoughts on growing and evolving within a Ruby application.

See Slides on speakerdeck.com

Big Ruby 2014