Maintainable Ruby on Rails

Refactoring

Steven Baker

@srbaker

#ruby-on-rails

#software-maintenance

#technical-debt

#refactoring

#design-patterns

#convention-over-configuration

#legacy-code

Maintainable Ruby on Rails

by Steven Baker

The video titled 'Maintainable Ruby on Rails' features Steven Baker discussing the challenges faced by Ruby on Rails applications as they age and how to address these growing pains through effective design choices and practices. As applications near their decade of existence, teams often encounter issues stemming from past design decisions which slow development and impact team morale. Baker emphasizes the importance of a long-term perspective when developing software, suggesting that today's choices significantly influence future maintainability.

Key points covered in the talk include:

Maintaining Applicability: The need for applications to evolve while avoiding common pitfalls associated with legacy code.
Practical Experiences: Baker shares anecdotes from his personal coding journey and projects, including his first program at a young age which became unmaintainable, emphasizing lessons learned over time.
Long-term Vision: The importance of planning for application maturity from the beginning and recognizing that what works now might hinder future development.
Renovation Mindset: Baker draws parallels between home construction and software development, advocating for thoughtful enhancements rather than complete overhauls when applications face challenges.
Conventions over Configuration: Adoption of sensible defaults in applications to facilitate easier onboarding and maintenance.
Documentation: Maintaining thorough documentation to support team members and ensure clarity around design choices.
Tackling Technical Debt: The accumulation of technical debt due to poor design choices needs to be proactively addressed, emphasizing the need for gradual resolution of these issues.
Signal from Tests: The health of the codebase can be gauged through tests, noting that slow tests and fragile tests are indicators of potential problems.

Baker concludes by stressing the necessity of continuous discussions within the development community to foster improvement in application design, advocating for proactivity in addressing technical debt and urging developers to enhance existing codebases rather than simply fixing immediate issues. By incorporating these strategies, developers can ensure their Ruby on Rails applications remain maintainable and extensible into the future.

00:00:24.560 This talk is about future-proofing your Ruby on Rails applications, which are now nearing a decade old. This talk will cover the things you can do to prepare your applications for maturity. I'll be asking some questions, and for the most part, I will just be talking about these ideas.

00:00:40.480 I write periodically at stevenar.com, and you can reach me on Twitter, although my Twitter feed can be quite vulgar, so consider yourself warned. Feel free to email me and share your thoughts on how much this presentation sucks; I welcome the feedback. My goal is to share ideas that we can explore together, similar to a parents' advisory council where we discuss how to improve our children's education. Instead, we can create a space to talk about how to develop our applications into responsible, mature software.

00:01:20.680 My first computer program was a hockey trivia game I created when I was just eight years old as a way to engage with hockey trivia. Looking back, the hockey trivia market was rather underserved, and I realized that the issue with my first iteration of the application was that it quickly became unmaintainable. I refactored it several times, but ultimately it became too difficult to add new questions and keep it interesting, leaving me devastated.

00:01:50.880 If I had known how to write maintainable software back then, I could have filled a valuable niche. Since then, I've dedicated myself to understanding how to make my applications future-proof. What decisions I make today will affect the work I have to do to fix my applications tomorrow and for years to come.

00:02:08.880 These are important considerations, and the questions are not always obvious. The decisions that seemed reasonable six months ago may be the ones that are hindering progress now. I learned about Ruby on Rails shortly after its release, and my focus has been on quality, testability, and future-proofing applications. Most of my six years working with Ruby and Rails have been spent dealing with difficult legacy code, as I often receive calls to fix 'the worst code ever.' While I can’t always solve the issues, I learn valuable lessons from each experience.

00:02:44.720 Pac-Man serves as a great example of enduring software. We still play it today, and it's fascinating how something created in 1980 remains relevant. Similarly, people still play other classic games like Tetris, which has persisted over the decades longer than anyone could have predicted. This shows that software often lasts longer than we anticipate.

00:03:10.920 I work in the finance industry, where we interact with systems designed in the 1970s that still operate effectively. This highlights the importance of considering how our applications will evolve over time and preparing accordingly.

00:03:34.680 As Rails applications reach their decade of existence, some are already approaching the ten-year mark in production. How many of you are working on Ruby on Rails applications that are more than five years old? It's crucial to acknowledge that there can be legacy code decisions that we wish we hadn’t made. While Rails simplifies getting started and allows for quick prototyping, building a full-fledged application requires long-term planning.

00:04:00.320 We need to be realistic about the future—what we implement today may not be maintained or supported by us down the line, especially in a small community like ours. It’s essential to be thoughtful about our work today because our peers will have to deal with it tomorrow.

00:04:30.480 I want to commend my colleagues Joe and Mike for leading discussions around maturity in the Rails community, touching on concepts such as object-oriented design. It’s inspiring to see these discussions because we can sit here today discussing how to prepare ourselves for the future.

00:04:48.280 Aging doesn’t have to be seen as a disadvantage, whether in software, cars, or people. Maturity often brings improvement. I’m learning and getting better with age, and I hope you all are, too. I want to share some effective strategies for enhancing your applications. We all know about the significant moment that DHH presented Rails back in 2006. Fast forward to 2012, and we find ourselves being the enterprise and the status quo.

00:05:21.040 We have an opportunity to avoid leaving messes behind for the next generation of developers. I had an impactful experience building a house with my dad a couple of years ago in the Canadian winter. We began each day by shoveling snow off the floor before doing any construction work. During this time, I learned more about software development than I had in my previous decade of experience.

00:05:55.640 This connection between building houses and writing software highlights a craftsmanship movement in our industry. Renovation is a significant part of the construction industry, where most work is focused on modifying existing structures. Similarly, when software applications need changes, we often view it similarly to demolishing a house and starting anew.

00:06:26.600 Over the years, I have often acted as the 'Mike Holmes' of Rails apps, coming in to clean up messes. The renovation mindset must retain a focus on enhancing existing systems rather than simply building from scratch when challenges arise. Unfortunately, in software, we tend to think we need to bulldoze the house instead of making thoughtful improvements.

00:06:56.120 While there’s a temptation to bulldoze and start anew, typically, it is not the best option. Building new software can be cheaper than renovation, but that’s not always the case. Many renovations can actually cost close to starting fresh. My experience has shown that there’s a disproportionate cost associated with rebuilding versus making improvements.

00:07:27.680 For instance, Steve Simmons is an MG car enthusiast who had to expand his garage instead of tearing down his whole house. In this way, we must also strive to enhance our software applications. Change takes time, and with the right approach, we can ensure that our apps evolve without unnecessary pain.

00:07:56.680 However, there’s usually a slowdown associated with growing applications. After all, development speed tends to decline for various reasons, often due to poor design decisions made early on in the lifecycle. Over time, as we learn about our applications and the domain they're in, we should ideally become more efficient at implementing new features.

00:08:16.360 Many projects, unfortunately, don't experience this ease because they fail to plan for the future adequately. It's crucial to shift our mindset from short-term responses to long-term solutions.

00:08:45.000 One strategy that brings significant value is adopting 'convention over configuration.' This idea will resonate even more in twenty years when Rails is just a memory. Much like how developers interact with legacy systems today, our future selves might look back at the Rails applications we build now.

00:09:04.640 If there’s one major takeaway from working with Rails, it’s the significance of convention over configuration. While it’s essential to configure when needed, leveraging sensible defaults can simplify teamwork and onboarding, ensuring that developers understand how to interact with the application.

00:09:28.440 As our applications grow and evolve, keeping conventions consistent helps teams align and maintain clarity. However, if we violate these conventions, we introduce a costly need to document and configure our systems, which can hamper overall productivity.

00:09:55.960 It's important to remember that maintaining documentation is just as crucial as adhering to code conventions. It aids onboarding and reduces confusion for new members and existing staff trying to understand previous choices and implementations.

00:10:17.680 Lastly, adopting the principle of 'leave things cleaner than you found them' can be highly beneficial. Whenever you work with existing code, take the time to improve it, even if it’s just a minor fix. These small contributions accumulate over time and significantly enhance the maintainability of the code.

00:10:38.080 Additionally, listening to your tests is crucial. Tests are not just for verifying correctness; they reveal the health of your codebase. Slow tests indicate slow code, and fragile tests often mean there's excessive coupling—these are signals you should heed.

00:11:00.440 Design patterns are also invaluable; they provide a shared vocabulary to discuss solutions and simplify communication across teams. Adopting established patterns can unify your team's approach to problem-solving.

00:11:19.720 Managing dependencies and understanding coupling are key for a healthy codebase. It's crucial to monitor how tightly your application is coupled to specific databases or external services, as this can result in costly rework when changes are needed.

00:11:42.840 In conclusion, technical debt arises from poor design choices that accumulate over time. Just like monetary debt, if not addressed, it continues to grow, leading to escalating problems. It's important to resolve these poor choices gradually as you better understand your project and its requirements.

00:12:04.040 Remember to fix issues as you encounter them; a proactive approach to technical debt will ultimately pave the way for more maintainable applications.

00:12:31.520 Thank you for your attention. Let’s continue to have conversations about improving our applications and share our experiences moving forward. Whether you agree or disagree with me, I encourage you to reach out on Twitter or GitHub. I value your insights and feedback.

LA RubyConf 2012