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.
