A Tale of Two Codebases

by Pat Maddox

In the video titled "A Tale of Two Codebases," speaker Pat Maddox shares insights on his journey and enthusiasm for Ruby programming, as part of the MountainWest RubyConf 2010. The presentation highlights several key themes around the professional development experiences of developers and the impact of programming languages on productivity and happiness in the workplace.

Key Points Discussed:
- Personal Journey with Ruby: Pat recounts his skepticism towards Ruby initially, transitioning from Java, and eventually embracing Ruby after discovering Rails. His excitement about Ruby grew when he started generating income from programming.
- Community Experience: Attending his first Ruby conference was pivotal, where he connected with significant figures in the Ruby community, leading to his involvement in RSpec.
- The Importance of Happiness and Productivity: Maddox emphasizes that happy programmers are more productive, explaining that Ruby's design philosophy, aimed at programmer happiness, aligns well with agile programming principles.
- Alignment of Business and Developer Values: He argues for the importance of understanding the relationship between developer satisfaction and business success. While developers seek professional fulfillment, businesses often prioritize financial outcomes, leading to potential conflicts in values.
- Agility in Development: The culture of Ruby programming promotes rapid development cycles. Maddox contrasts traditional long development cycles with agile approaches, where features are regularly delivered, enhancing business responsiveness.
- Avoiding Burnout: He warns against the dangers of over-extension and the need for a sustainable work pace while maintaining high-quality code standards.
- Quality over Quantity in Code: The importance of code quality is highlighted, with emphasis on refactoring, maintaining a clean codebase, and ensuring adequate testing to support long-term project success.

Conclusions and Takeaways:

- Programming can revive passion through enjoyment and community involvement, as exemplified by Pat’s own story.

- Happiness in programming roles leads to improved productivity and can benefit the overall business model.

- Developers should champion sustainable practices, avoid overcommitment, and promote a culture of excellence to attract and retain top talent.

00:00:15.679 All right, hello everybody! My name is Pat Maddox, and I am talking to you today about 'A Tale of Two Codebases.' If you read the talk description or looked at the slide and thought to yourself, 'What the hell am I going to talk about?' I am right there with you. I submitted a couple of talk proposals, and when I got an email saying, 'Hey, you’re going to speak,' I thought, 'Really? You guys chose that one? How am I going to do this?' So with that said, that's my official title in the Ruby community, which you guys may not know: BDD MF. That stands for Behavior Driven Development Mofo, a title given to me by Dave Schlemski, which was kind of cool. Thank you all for coming out; this has been a fantastic conference so far. Pat, Mike, and everybody else involved, I really appreciate you organizing this, and the content has been amazing. I've heard that MountainWest RubyConf is the best, and it hasn’t disappointed.

00:01:20.479 As we're kind of ending here the day and the whole conference, I hope to carry the baton to the next developer. So, really quick things about me: I work for a company called Goldstar.com, where we sell tickets. This picture shows me at Goldstar, really excited because we were having an ice cream party after a great day. I tend to get excited about a lot of things, and one of those is Ruby.

00:01:47.760 To illustrate my excitement for Ruby, here's a completely made-up plot chart of my enthusiasm for Ruby over the last five years. I tend to shy away from long background discussions about myself, but I think this sets the stage for everything. If you can see on this chart, it’s relative to Java, which is what this represents. At the very beginning, I was a skeptic; I remember thinking 'This doesn't even have semicolons—I'm not interested!' because I had learned C, then C++, and then Java, and Ruby looked really weird to me.

00:02:22.720 However, my friend called me a dumbass and told me about Rails, which prompted me to give Ruby a second chance. Eventually, I crossed the threshold from thinking, 'Okay, I can see this is a little cooler than Java,' to actually writing my very first Rails app, which was pretty fun. I thought, 'Hey, I’m getting a lot of stuff done here—I’m not writing EJBs anymore!'

00:03:04.800 A few months later, I actually made some money from Ruby—this is where my excitement really soared because going from 'Hey, I’m coding for fun' to 'Hey, I did something for fun and someone gave me money for it' is exhilarating! This was all a little over five years ago now, and after some time, I got to go out to San Francisco to work for my first startup. I thought, 'Now I am in the whole startup world,' but pretty quickly I realized that $50,000 in Colorado goes a long way, while that amount doesn’t stretch as far in San Francisco. That was the only downside to my Ruby journey; it was thrilling but left me wondering, 'How am I going to buy food?'

00:04:00.000 I then attended my first Ruby conference, and that was where I got involved in the community for the first time. I started meeting people, and it’s a silly story, but I was a huge fan of Dave Astels' work because he wrote a book on Test-Driven Development and another on Agile practices, which I thought were really cool. On my first day at the conference, I went to the bathroom and ended up peeing next to Dave Astels, and I thought, 'Oh my God, that’s so cool!' I even texted my friend, the one who introduced me to Ruby and Rails, and I said, 'Dude, I just peed next to Dave Astels!'

00:05:06.559 About a year later, I actually met Dave Astels, and we became friends because I eventually got involved in RSpec. A bit later, Dave added me to the RSpec core team. I became friends with Dave Astels about a year after that, and I think it was about a year after that when I finally felt comfortable enough to admit that story to him. So, I was programming Ruby, and I was with a company called Market7 in San Francisco, and we worked with Pivotal Labs. I think there might be some Pivotal folks here, and they are phenomenal.

00:06:15.439 I had read about Extreme Programming for a long time and had done some of the practices, but when I was with Pivotal, that was where I witnessed how programming could be really fun. You get so much done, and it creates a great experience. Over the past year, I’ve been fortunate enough to go to Scotland, to Hawaii, and to MountainWest RubyConf, doing all these really cool things, and I’m just riding this high wave right now. I’m telling you all of this because I hope it illustrates that I really love Ruby. I don’t mean I just like Ruby or think it’s better than other languages I could be using; I genuinely love coding in Ruby. I love talking to people here.

00:07:54.080 A big reason for my excitement stems from the fact that about a year before I started learning Ruby, I was playing poker online. I dropped out of college because I hated software development courses. It turns out what they teach isn’t fun, so I was fearing that everything I learned about programming wasn’t relevant to the real world. It turns out that playing online poker for a living is also quite hard. There were a couple of months where I slept in several layers because I couldn't pay the heating bill. So, to me, Ruby is really sweet now.

00:09:00.000 Ruby reignited my passion for programming. Throughout my life, I wanted to be a jet fighter pilot, but eventually, I wanted to be a programmer, and Ruby brought me back into this world. I was quite nervous about giving this talk, especially after hearing Joe up here fry my brain with his presentation. However, it turns out that there are precedents in the Ruby community. There’s DHH, who many of you know, who says, 'Be happy; that’s the whole point behind Rails.' And Matz, who created Ruby, did so to make programmers happy.

00:10:09.839 Although, to be fair, in one picture of Matz, he looks really happy, but it turns out it’s because he pulled a fast one over the Ruby community with this Python book. So, I genuinely love Ruby, and there are real reasons behind it. Firstly, I consider myself an object-oriented bigot. I enjoy learning about functional programming and other paradigms, but when it comes to designing my code, it's all about objects for me. Ruby is a very low-ceremony object-oriented programming language.

00:11:27.839 Additionally, the metaprogramming facilities in Ruby are fascinating. You can spend so much time thinking about how to mess with classes and how to make objects do things they probably shouldn't do. And if you don’t know much about metaprogramming, I assume everyone here is fairly competent, but learning to metaprogram in Ruby is akin to dating supermodels, as opposed to former high school cheerleaders—you're at a whole different level of capability and, therefore, feel more powerful. And, of course, we have open classes. Another program might have great ideas about how to structure things, but they don’t know better than you do in your specific context. Being able to open up a class and say, 'I like what you’ve done here, but I need to change it in this way,' without writing multiple design patterns is another significant reason why Ruby has captivated me.

00:12:36.640 So I love Ruby, and that’s only my perspective, but you all love Ruby too, and there are tons of reasons why Ruby programmers adore it, including the ones I've mentioned. One of the key benefits is our productivity. It turns out that happy programmers are productive programmers, which is a point I am driving home—happiness matters—from the top down. This comes from Matz, DHH, and others; it's part of our culture and separates us from many other programming languages. Your quality of life as a computer programmer truly matters within our Ruby community.

00:13:59.040 We care about numerous things, including open source. Many other communities are big into open source, but we thrive on taking code out of our real applications and opening them up for discussion. We love being happy, and we know some of the things that make us happy. However, it turns out we often work for business people—just to check in, how many of you here have a boss? A lot of people are coding in Ruby to put food on the table. What do bosses and business people like? They like money. Money makes business people happy, and I’m not going all communist on you, suggesting that they shouldn't be happy with their profits.

00:15:23.520 But what you have to understand is that while that guy looks incredibly happy at his big pile of cash, he’s also going to say, 'I’ll make you happy by giving you some money,' but you have to comprehend that they are not perfectly aligned with our values. Their happiness can often jeopardize our escape routes, and it can happen unintentionally. The point I’m driving home is that there is a business case for happy developers. This is not an 'us versus them' situation. We know that productive programmers are happy, and when developers are satisfied, productivity rises.

00:16:40.000 If you have happy developers, there are lots of factors involved. Many of you probably love clean code. Who here enjoys dealing with horrible, nasty spaghetti code? We also appreciate having a test suite; and it’s not just about having tests—but having fast ones that sufficiently explain the associated code to improve our productivity. We even like documentation with YARD! So, there's the logic—happy programmers translate into productive programmers. If you're productive, you're happy, and if you're happy, typically you're more productive.

00:18:00.000 Moreover, you create an environment that attracts other good programmers. If you have a team of talented developers who are excited to work together, you will naturally attract top talent. This is a concern for your CTO or project manager, but you, as a developer, should also prioritize it. When you look to your left and right, are those people as good or better than you, or are you pushing each other to take everything to the next level? We all want to be happy.

00:19:06.480 However, the business goals and our values don’t always align, though there’s one point we can agree on: agility matters. Being able to respond to change quickly, adding features without high bug rates, and producing consistent value on time are all critical. Here’s another chart I made, though I admit it's somewhat hand-wavy—primarily because I have never worked in traditional software development. From conversations I’ve had with others, the traditional development cycle is often discussed as a period spanning months or even years. Programmers spend significant time, like six-month cycles of development, before any release takes place.

00:20:32.080 In contrast, if you look at agile literature, developers often focus on cycles of days and weeks, releasing features more regularly. Ruby isn't technically a methodology, but talking to Ruby programmers, you’d find that they often think in terms of hours and days—creating new values for the business within that timeframe. It’s common to see Ruby teams releasing updates weekly or biweekly. Is anyone here releasing their code two or three times a week? Anyone doing continuous deployment yet? Well, we’re not there at that level, but it's an enticing idea!

00:21:36.560 This presentation is dubbed 'A Tale of Two Codebases,' and I initially had a brilliant story in mind about addressing inefficiencies in codebases over time. I told it to several people who said it made no sense, so I revised it and again faced the same response. After a couple of iterations, I finally threw in the towel. And here is a picture of Jessica Alba commuting to work on a hippo—for the sake of a laugh!

00:23:10.399 Back to agility: we, as Ruby programmers, can move very fast, which delights our business stakeholders. But sometimes, slowing down is equally necessary; the Agile community calls this concept 'sustainable pace.' This concept asserts that not all 40-hour work weeks are created equal. So, consider the difference between a programmer enjoying their time writing Ruby code on a beach, versus workers in a high-stress situation on a crab fishing boat in the Arctic. In any given work week, you will either emerge invigorated and eager for the next work period or drag yourself through the motions, feeling your energy diminish over time.

00:24:40.800 We want to avoid teams that find themselves drained over time. When companies lose their talented developers, they often leave, and the results are detrimental. Here’s an analogy: imagine a shantytown. If developers refrain from doing adequate architecture upfront when building software, the outcome resembles a collection of small houses and markets that work reasonably well but fail to scale. For instance, if your ambitions are to accommodate one million users in your application, the approach taken during the first two months can drastically differ when working on a software project for two years. It begins productively enough, significantly benefiting your community, but as it matures, if the town lacks roads, commerce will stagnate. Similarly, without proper organization, systems begin to falter.

00:25:55.839 Consequently, if you want to enhance your project and continually add value, you need to keep examining various aspects of the codebase. The primary indicator of code quality is reported through the comic about unwanted surprises per minute; needless to say, you know how many times you've said 'WTF?!' about bad quality code. Everyone here is aware of what constitutes the poor quality of your codebase and the numerous things you want to improve. If you are working with Rails and your test suite is sluggish, you likely want to make that faster. There are various strategies you can utilize: decouple code where necessary, minimize database hits whenever possible, upgrade to the latest Rails version, or even consider moving to NoSQL platforms since, as we know, MongoDB rules!

00:27:17.760 I had planned to offer specific strategies for testing, refactoring, and enhancing productivity, but during my audience assessment, I realized that everyone here is already well-versed in that knowledge. You guys already know how to refactor. What I need to impress upon you is the importance of driving this knowledge back to your teams—ensuring it is instilled in their practices because not doing so will harm your long-term success.

00:28:51.439 The first point we need to establish is that we demand excellence of ourselves, of our team members, and of our bosses. We must communicate our understanding of what must be accomplished as software engineers. Yes, there are times we have to make concessions to meet deadlines, but there's always room to refactor code and add tests, even if that can become a challenging negotiation with project managers. However, neglecting this principle will inevitably lead to burnout, which drives developers away from your organization. This does require immense focus because many people are trying to divert our attention to their needs, but as a team, we must fight back against that fragmentation.

00:29:57.600 So even when you find yourself spread too thin, you need to remember not to bite off more than you can chew. If you look at this image of a massive burger from In-N-Out, you might see how daunting that can be. I have no idea how someone could approach eating that colossal burger! Just as it might kill you to take on too many projects at once, you can find yourself mentally exhausted by spreading yourself across too many areas without making tangible progress. Likewise, nobody enjoys working with buggy and difficult-to-understand code, as those frustrations often lead to conflict!