00:00:24.800
The thoughts I had my first semester's proposal and where I ended up now is a little bit different. I'm not going to be quite as technical, but I will do my best to see.
00:00:39.440
Before I start, let's see a show of hands. Who here is working on Ruby? How many of you have ever joined a team with an existing app because it was growing and successful? All right, that's the majority. How many people here have ever hired someone to join their team because the app you were working on was successful? Okay, so one thing I want to talk about is how we move forward with success.
00:01:14.960
The first thing I want to get out here is that you might be a pain to your business. They do not like you; they don't care about your app, and they don't care about your code quality. They only deal with you because it is financially worth it for them. The amount of pain they deal with varies by company. Some places will put up with dress codes, while others will allow remote work. But at the end of the day, every company has a different pain tolerance when dealing with you, and their pain is not your pain.
00:02:01.759
Who here has worked on an app that's a piece of junk? Raise your hands. How many people have worked on a Rails app that's a piece of junk? Okay. I'm really curious as to why the apps we work on often turn out poorly. We're all self-selecting developers; we're here because we want to improve. Yet we often find ourselves working on assets that are of low quality. Why is that? One reason is that some apps were designed as demos but were then shipped straight away, which is a bad practice.
00:02:34.400
Another reason is the lack of experience of the original team. High turnover and inconsistent code quality contribute as well. If you ever find yourself needing to understand the anthropological history of your app to grasp why certain decisions were made, that is a clear sign of a bad app.
00:03:11.800
Is anyone here familiar with Conway's Law? It states that organizations which design systems are constrained to produce designs that mirror the communication structures within those organizations. This relates back to the point where you are a pain to the business. Sometimes, business people don’t want to communicate with you because they don't have a vested interest in it. This lack of communication structure will manifest in your app.
00:03:43.760
Now, I find it frustrating that we can work with Ruby but face pain in our apps due to influences outside our group. Early on in the Ruby community, I learned that Ruby is designed to make programmers happy. It pains me when I'm not happy while working within this environment.
00:04:14.879
I’ve worked on multiple applications over time and faced similar issues repeatedly. What's the number one problem we encounter? If you could summarize the issue with Rails apps that makes them difficult to maintain in one word, what would it be? The answer? The single monolithic architecture throughout the entire application. This is the biggest issue.
00:04:43.760
I've transitioned between companies and organizations, and the most significant problem I see is apps that are just a monolithic ball of mud. They do way too much, and that distresses me. Typically, this indicates there's no clean separation of responsibility within the model.
00:05:01.680
Have you ever opened up a Rails app, and it has like 25 controllers and 23 models? Everyone here has worked on apps like that, right? That’s terrible. On the flip side, you may have a situation where your models are overly complicated, as they just took a 2000 line post model and split it into different files. This isn't a sign of good structure; it's a sign of a very fat model.
00:05:51.680
Unfortunately, Rails makes it easy for developers to shoot themselves in the foot. While Rails provides good conventions for MVC and tells you where your code should go, it offers very little guidance on structuring it properly.
00:06:43.920
So, I want to first discuss the models. Your models typically end up getting the majority of attention in our apps. But before that, I want to take a slight detour and discuss testing because it's another major issue.
00:08:03.760
Who here has ever been paid to work on an app that has very little testing? Let’s be honest; that’s pretty much everybody, right? This is an ongoing issue. And who is currently working on a project that has subpar testing? Again, that seems to be the majority.
00:08:53.600
We're not all going to become masters at testing overnight. However, I want to touch on a couple of key points about it. The first is, testing is part of development, and it's not quality assurance (QA). Tests should ease pain, similar to how businesses endure pain to gain value from us and the applications we build.
00:09:50.560
We have pain in many areas that testing can help address. The first pain is determining what the app is supposed to do. Test-driven development provides guidance, laying the groundwork for what the application is meant to accomplish. Additionally, tests aid in easing the pain as we refactor our application. However, we shouldn’t confuse testing with QA.
00:10:24.799
When dealing with monolithic apps, pain is inevitable, and testing can alleviate that. The issue with many apps lacking good test coverage stems from the distinction between non-test driven lines and those that are test-driven.
00:11:11.760
The curve for those without tests climbs steeper over time, as fixing bugs or adding new features results in higher costs. Developers sometimes choose not to include tests as they believe it will prolong the development process. What results is a perception that testing equals pain, which needs to change.
00:11:46.240
We often confuse testing with development time. In reality, model tests are cheaper and yield better returns than comprehensive browser-based tests. Integration tests can provide a false sense of security, while model tests offer deeper insight into our applications.
00:12:04.560
When approaching Rails apps, I have two rules: I want declarative code, meaning I prefer code that states what it does instead of how, and I believe in maintaining consistent levels of abstraction. For instance, if you're breaking down processes, ensure it’s done within different methods to avoid convoluted logic.
00:13:43.760
Here's an example—using a helper method that declares actions like joining or dropping a course, rather than embedding complex checks within your views. This approach consolidates logic and clarifies intent, making it much easier to maintain and test.
00:15:17.680
To emphasize the significance of level of abstraction, when faced with complex if statements and conditionals, it's better to delegate functionality to helpers rather than cluttering views. This practice leads to more maintainable code, improving testing and overall quality.
00:16:04.799
Additionally, making use of presenters to encapsulate view logic is invaluable. Presenters can serve as view models, helping separate concerns, which allows for easier testing of logic that would otherwise be buried within views.
00:16:55.360
Throughout different levels of our stack—models, views, services—we need to ensure we focus on splitting our applications correctly. There’s a wonderful book called Real-World Software Development Patterns that I recommend.
00:18:18.880
As we explore success, how do we build a team around it? What does it mean to code effectively? Code represents someone else's problem. It's how we transform abstract ideas into concrete forms. The legendary book, The Structure and Interpretation of Computer Programs, emphasizes that computer science is about controlling intellectual complexity, and programming is inherently a human activity.
00:19:26.880
The reason we struggle with software is often due to our culture's tendency to minimize the human aspect of our work. Focusing solely on machine efficiency can lead us astray; hence, we must prioritize human interaction and communication in programming.
00:20:44.720
I genuinely enjoy being here at conferences because the audience here is self-selected; you are passionate about improving your craft. However, I do wonder about the 80% of developers who aren’t here. We can spend time establishing coding standards, but our work is intertwined with ideas, and we must not underestimate the importance of collaboration.
00:21:34.720
The human element is essential in achieving scalable applications that meet business needs. While it may seem tempting to focus only on attracting top talent, the true solution lies in nurturing and enhancing the skills of the developers we already have. Everyone has potential, and we can foster growth.
00:22:12.960
The dynamics of the team are crucial. It's not enough just to assemble a group of talented individuals. Without fostering good team dynamics, even the most talented teams can become dysfunctional and fail to deliver.
00:23:05.440
So remember to prioritize collaboration and support among team members. You all are amazing, and the message I'd like to leave you with is to embrace and appreciate the journey of working together, because ultimately, friendship is magic.
