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.
