Ruby Code Quality with Ernesto Tagwerker

Are you working on Ruby on Rails Applications that are constantly on fire, overwhelmed by technical debt? Instead of being a firefighter, what if you could be a happy programmer again? Listen and learn exactly how to measure tech debt and take the right steps to immediately improve code quality!

Are you working on Ruby on Rails Applications that are constantly on fire, overwhelmed by technical debt?

Instead of being a firefighter, what if you could be a happy programmer again and “Escape the tar pit”?

Learn exactly how to measure tech debt and take the right steps to immediately improve code quality. Listen to our conversation with Ernesto Tagwerker (@etagwerker).

Apple Podcasts | Spotify

About our guest

Ernesto Tagwerker is the founder & CTO at FastRuby.io & OmbuLabs.

He and his company are the maintainers of many code quality projects: skunk, rails_stats, metric_fu, and rubycritic, and many other important Ruby gems such as database_cleaner, bundler_leak, and next_rails.

He’s an expert in upgrading and improving legacy Ruby on Rails applications. He taught us some step-by-step strategies you can follow to quickly measure and improve code quality.

Show Note

Ruby Code Quality with Ernesto Tagweker - Transcript

[00:00:00] Stefanni Brasil: Hey, there! Stefanni here. Before you listen to this amazing episode, we have something to ask you!

[00:00:06] Thiago Araujo: Feel like you’ve been stagnating in your current position as a Ruby on Rails developer? Working on projects that aren’t getting you to the next level? Stuck in a mid-level position?Have you been applying to jobs and getting rejected?

[00:00:21] Stefanni Brasil: It can be hard to improve your skills outside of your work. What if you knew exactly how to get your Software Engineering skills to the next level?

[00:00:31] Thiago Araujo: hexdevs.com/workshop and get on the waitlist today!

[00:00:51] Stefanni Brasil: Enjoy the episode!

[00:00:52] Thiago Araujo: Ernesto Tagwerker is the founder and cto@fastruby.io and OmbuLabs. He is the maintainer of database cleaner bundler leak, and next rails. He just told us today that fast Ruby has recently inherited other important Ruby code quality projects, such as. rails_stats, metric Fu and Ruby critic, which is a great gem.

[00:01:26] Thiago Araujo: We watched your talk in a previous watch party. Uh, the talk is name escaping the Tar Pit. Thank you so much for such a great talk. People got surprised with thegems that you mentioned so many genes that can use to improve code quality. So that’s really amazing and yeah. Welcome Ernesto. It’s so great to have you on the.

[00:01:48] Ernesto Tagwerker: Uh, Thiago and Stefanni, thank you very much for having me. And, uh, yeah. Also for hosting a watch party for my talk on code quality on skunk. Uh, it’s great to be here.

[00:02:01] Thiago Araujo: And by the way, what else has gotten people surprised by your talk? Do you have that information? Yeah, I think I’ve gotten some really positive feedback from a lot of developers.

[00:02:13] Ernesto Tagwerker: I presented this talk and the Philadelphia Ruby meetup, uh, Ruby confu S RubyConf Australia. And I got a bunch of comments from people and mostly positive. And some comments are from people who don’t believe in code coverage. So. Yeah, I definitely stood out because I believed like code coverage as a metric has always been something that adds value and builds trust and an application.

[00:02:42] Ernesto Tagwerker: And knowing that 70% of the code is covered by tests, uh, usually is a good thing in my book, but there are some people out there that don’t believe that. And that sometimes, you know, they have had bad experiences where they have. An application that had 90% code coverage, and then they opened the test suite and they just looked, it was exercising the code, but it was not expecting anything from the code.

[00:03:10] Ernesto Tagwerker: Yeah, I guess there are outliers out there of people who have gamed the code coverage metric, but I don’t believe that takes the value away from that metric. And. Escaping the Tar Pit is mainly focusing on churn, complexity and code coverage. By combining, combining all these metrics. The idea is that you can get insights from your code base and know what things you can improve next to reduce tech debt and in your project.

[00:03:42] Thiago Araujo: It’s interesting that you mentioned people that don’t, don’t like this metric very much code coverage. We also have to be careful with. Uh, the test suite, because it’s still code, right. It’s not just some crazy code that you write just to do some asserts. So the test suite is also code slate. It should be good code.

[00:04:04] Thiago Araujo: Right? So this is one of the problems that I see sometimes where people treat their tests, not with the same care and consideration compared to their code.

[00:04:15] Ernesto Tagwerker: For sure. Yeah. In terms of, you know, running a test suite that is. A good test where it is like, yeah, what is a good test suite? Sometimes you do have like really good code coverage.

[00:04:27] Ernesto Tagwerker: Let’s say 80%, but the test suite fails one or seven times out of 10 times that it runs because it has flaky specs in there. You need to be careful about the quality of the test suite as well, so that you can trust that it executes. It tests the behavior of your code, but also it doesn’t frustrate you when you’re trying to run it and you get to like rerun and rerun and rerun.

[00:04:55] Ernesto Tagwerker: That’s definitely something you want to avoid and, uh, definitely improve if you find that in your application.

[00:05:01] Thiago Araujo: For sure. And one of the things that is also important is the performance of the. Test suite, because like you mentioned, sometimes you have flaky tests and you want to run the test suite on CI or on your computer, but then it takes a long time, like 40 minutes now, or to run and then something fails and then you have to run it again.

[00:05:24] Thiago Araujo: It’s kind of annoying. Is there any tip you can share to. Maybe improve the performance, like testing parallel, things like that. Yeah.

[00:05:33] Ernesto Tagwerker: That’s usually what we see in our clients. Um, it’s got fast Ruby that I, oh, we work with clients that have been running rails for the past 10 years. So as time goes by, their test suite takes longer and longer.

[00:05:47] Ernesto Tagwerker: So what they end up doing as. Parallelizing their test suite to run it multiple shards or jobs. And that way they reduce the total time that it takes to get the feedback from their test suite. But, uh, yeah, I don’t have a lot of, uh, advice in that sense. I think it’s important and there are definitely gems out there that help you see what.

[00:06:11] Ernesto Tagwerker: Scenarios in your test suite are the least performance. If anything, if you notice that your test suite is super slow to find gems that can tell you like which ones, which scenarios are the slowest ones. Sometimes the slowness is because of. Consuming like a third party API that you shouldn’t funny story.

[00:06:33] Ernesto Tagwerker: I once did that and ended up finding a security hole in an API that I was using. But, um, yeah, don’t do that. Try to stub and mock all those third party services. So they don’t have to slow down your test suite.

[00:06:50] Stefanni Brasil: Let’s say I’m a developer that is working on the code base that I simply know it is a mess, but I have no idea how to get out of it, how to get started.

[00:07:02] Stefanni Brasil: Maybe the tests are in that situation that we are just discussing now. And the easiest solution is to find another job. What would you say is another alternative? What would you advise me?

[00:07:16] Ernesto Tagwerker: Um, oh, that’s a good question. I think the main thing is to think about why are you in the tar pit? Like, why is it so hard to ship small changes?

[00:07:26] Ernesto Tagwerker: Why is it that. Tweak small things in your application and seven different things break. Why is it so hard to find root causes for bugs? And that ideally will tell you like, okay, there are a bunch of things that are wrong with your code base. I wouldn’t recommend that you take. Three months to pay off all the technical debt.

[00:07:49] Ernesto Tagwerker: Uh, I don’t think that’s a good approach to say. Um, yeah, I’m going to take three months to fix all the technical debt and then everything’s going to be fine because it’s a, it’s basically a habit that you need to build in your team and sometimes you do need, um, All the time you need management approval to say every week or every sprint we’re going to dedicate 10, 20% of the sprint to paying off some of the technical debt.

[00:08:18] Ernesto Tagwerker: If management in your company is not open to something like that to like gradually pay off, you know, 20 minutes, an hour of technical debt in every sprint. I think then, yeah, maybe you do need to find another job or you need to. Continue to try to communicate why it’s important to pay off technical debt because we write Ruby code and we understand that program.

[00:08:44] Ernesto Tagwerker: Your happiness is very important and Ruby gives us great tools to write code that makes us happy. But of course, as the application evolves and as many hands. You know, submitting changes and all that. There’s always a possibility that it will become super complicated and super hard to maintain. You know, there are very small things and I really like, uh, Ben Orestein, uh, code quality challenge.

[00:09:11] Ernesto Tagwerker: Um, he has this initiative where you can do one thing at a time and it’s just like 20 minutes and you do this thing for 20 minutes and then, okay. You pay it off a little bit. Yeah. Of the technical debt. It could be something as small as, okay. We have a test suite. We want to see what the code coverage percentage is.

[00:09:30] Ernesto Tagwerker: So we’re gonna add, you know, this snippet of code and at the end of every CI run is just going to tell us code coverage is 50% or 51%, but adding that change should take you less than 20 minutes. And that gives you an idea of where you are in terms of code coverage. Another thing that you could do after that is to.

[00:09:53] Ernesto Tagwerker: Skunk to your project and say, okay, after you get code coverage for the test suite, run skunk and tell me which files are the most complex and have the least coverage. And of course, these are all like research activities that you can do to kind of find your location in a map. And then once you know your location, you can actually take.

[00:10:19] Ernesto Tagwerker: Decisions to move in the right direction and slowly pay off technical debt. I like the approach of doing small things in that consistent basis, because if there is, if it is something that it’s not already part of the culture, you probably don’t want to try to force everyone to do it. I don’t know, every day or every week, something like that.

[00:10:44] Stefanni Brasil: I also liked how you suggest. Just doing something small that you can do without perhaps even needing approval from management. I believe that that’s one of the main reasons is it’s not the priority of the company. Do you think it’s possible to do it even without having any support from your team?

[00:11:05] Ernesto Tagwerker: Yeah, for sure.

[00:11:06] Ernesto Tagwerker: I think, you know, it’s definitely not the best path, but if you don’t get approval for management, if they’re like, no, we’re, we’re going to. Continue with our approach of, you know, dedicating two sprints a year to pay off technical debt. What you can do is with every change use ship, or which would every patch that you ship, you can slowly pay off technical debt is going to take you a little longer, but let’s say you’re fixing a bug.

[00:11:37] Ernesto Tagwerker: So you use TDD. You write the test first to reproduce the issue, and then you fix it. And then. That’s a very small way to ship, not just the patch, but also test that, you know, make sure that there’s no regression in the future. Uh, if there is no test suite and you want to do this, basically just start with very small tests that just tests that one method that’s failing and boom, you have like a test suite.

[00:12:06] Ernesto Tagwerker: It only covers like 1% of your code base, but at least 1% is higher than 0%. So. That’s great. If you’re working on changes that are like a little bit more involved, what you can do is gradually change some of the portions of code that you’re using. Touching. So, you know, like the it’s called the boy scout rule or where you go in and you do your thing, but then when you come out, the, the code is better than when you started doing the thing you were doing.

[00:12:37] Ernesto Tagwerker: So let’s say you had to touch, you had to touch a file that has a thousand lines and maybe. While doing your work, you notice like, oh, well they’re clearly two responsibilities in this file. So break it down into two files. And now you have two files of 500 lines, which is a little more manageable. Now of course, some managers and some.

[00:13:00] Ernesto Tagwerker: Code reviewers are going to go and say like, why are you doing this? Like your task was to fix this button and your can be like, well, yeah, it was to fix the button, but I also want it to improve the code base. And I mean, ideally you won’t get in trouble for it because ideally you are reducing complexity and making things simpler.

[00:13:22] Ernesto Tagwerker: But if you do get in trouble for it, yeah, it might be a good time to find the, a new job. And my company’s hiring, you know, and we appreciate people who go the extra mile. So feel free to, yeah, for sure.

[00:13:37] Thiago Araujo: So if you’re listening in, you’re working at a place that don’t do appreciate good code quality, it can just talk to your Ernesto and get a job at fastRuby

[00:13:46] Thiago Araujo: I really like your approach because it’s easier to lead by example. So if you’re working at a place that doesn’t. Great engineering culture and you don’t care much about tests. I had that experience in the past and it’s kind of annoying. And the only thing I could do was I had to lead by example, it’s kind of tiring and frustrating, but whenever I worked on something, I try to add at least the beat, a little bit of tests and do some refactoring and things like that is not always possible of course, but I think that everybody appreciates when.

[00:14:22] Thiago Araujo: That’s, you know, even if they don’t do that, even if your peers, they don’t really write tests or they say, oh, we don’t have the time or whatever, if there is no culture related to that, but they always appreciated. So they say, oh, you had some tests here. That’s great. And they, they even talk about it later.

[00:14:42] Thiago Araujo: Oh, did you see, uh, uh, the task for this code base? They start learning more about it, but I think everybody likes it. Everybody appreciates, uh, tests. Yeah. Leading by example is, uh, is another idea.

[00:14:54] Ernesto Tagwerker: Yeah. I wanted to ask you folks, um, about that. Like, have you ever tried following this approach and you found that.

[00:15:05] Ernesto Tagwerker: The person reviewing it or your boss did not appreciate it because as I said, this takes more time. So maybe you took four hours instead of one hour, or maybe took like two days instead of like two hours. Uh, but did you ever experience like pushback when ever, uh, this happened? In my experience, it was actually hard.

[00:15:28] Stefanni Brasil: I was still learning the best practices for testing. I knew they weren’t testing that behavior that much. Like I didn’t trust the tests that much, but also I didn’t know how to improve them a little bit. So it was extra hard for me because I wanted to improve, but I also didn’t have the support or yet the, the knowledge to do it.

[00:15:49] Stefanni Brasil: And I think maybe that might even be one of the main reasons why. It’s extra harder sometimes for some people, depending where they are working is I do have to drive. I do know this is not good, but I, I don’t know, but I am the one who cares.

[00:16:06] Ernesto Tagwerker: Yeah. I think, um, you know, as, as developers, you know, were, who are getting into a project or a new client that we’re working with, we’re always eager to fix things, right.

[00:16:19] Ernesto Tagwerker: And to make things better. And sometimes, yeah, it is hard to balance. The fact of like, okay, you’re learning a new system and not just a new system, a new culture, new best practices, new coding style, all, all of that. So it’s like, okay, how long does it take for you to learn? Like the way a team works and an application was built and the minute you start submitting like this small changes to pay off what you think is technical.

[00:16:50] Ernesto Tagwerker: That’s why I like the idea of like, establishing kind of like a baseline of code quality and saying like, okay, these are the tools we’re going to use. Where are you going to use Robocop? We’re going to use, um, Ruby critic and we’re going to use simple cough to judge quality and like the changes and then the code base.

[00:17:10] Ernesto Tagwerker: Uh, and I think only after you have set a baseline, you can probably be more comfortable about the changes that you think will. Move the project in the right direction. Everybody has the same understanding, but yeah, I think it is hard. To adapt your own ideas to like someone else’s project. And especially as a consulting shop, like we are, we have a hard time with that and we just need to make sure that we respect the, the practices that our clients have.

[00:17:41] Thiago Araujo: It seems to me, I seen that you mention you develop software for clients and do you have to convince them. That’s so important. Do you need a budget for tests or do you just say, oh, I’m going to build this feature. I’m gonna upgrade your rails version that. Kind of included in the budget?

[00:18:00] Ernesto Tagwerker: Well, we are a consulting shop and we work on two types of projects, mainly like we build new applications for companies and entrepreneurs that have an idea and want us to build it for that sort of project.

[00:18:16] Ernesto Tagwerker: We certainly ship code, but also code comes with test suites. So we. Don’t even mention it when we’re talking about it, but if there’s someone technical in the client side and they want to know how we work, it’s like we ship code, but we also shipped to a test suite with it to make sure that their behavior is always.

[00:18:39] Ernesto Tagwerker: Now for rails upgrade projects. Um, the things that we do is we don’t really touch the test suite that much, to be honest, we might tweak little things, but an ideal project for us is a project where we change all the libraries underneath the application and some of the code that uses the rails, API and Ruby API.

[00:19:04] Ernesto Tagwerker: And. The test suite continues to pass, you know, in rails four, two and rails five. Oh. So we don’t really write a lot of tests for the rails upgrade projects. Uh, we do have like a pretty high threshold where we tell our clients if they don’t have. 70% or more in terms of code coverage, we can’t really take on their project.

[00:19:27] Ernesto Tagwerker: Uh, and we do that because we learned, we learned the lesson in previous projects where we took on clients that had 50% code coverage and. We presented our estimates and then our estimates were off because manual QA took a way longer time than just running the test suites. Uh, an automated test test suite.

[00:19:49] Ernesto Tagwerker: We, we only take clients that have like a solid, solid tests. Uh, and it’s not just about code coverage for us. Like, it usually means like if we’re talking to a potential client that doesn’t have a test suite coverage is 0%. It’s a major red flag for us. Uh, it’s not just tech debt. It’s probably culture.

[00:20:09] Ernesto Tagwerker: Debt is probably like, you know, communication that tooling that, and. What we usually propose to these sort of clients is to work with us, to create a test suite that tests like the critical flow of the application. But, uh, so far nobody has taken us up on that offer.

[00:20:30] Stefanni Brasil: I found it really clever how you filter out the clients.

[00:20:35] Stefanni Brasil: And all that I can think of is that will be a great question to ask in a job interview. We usually ask, how is the. Tech dev culture if we get there, but usually is how is the team culture valuable would be really good to ask. How good is the test coverage? How is the culture with tests? I never thought of asking that, but I, I think it could also be applied to top interviews.

[00:21:02] Stefanni Brasil: Yeah, I think that would be a good idea. I know that there are tools out there, like cold climate and. Seen, um, that help, you know, clients and projects have like, uh, an eye on the code quality of the application. But when I built skunk, the idea was very ambitious of course, to say, okay, maybe in the future, someone will say, what is your skunk score?

[00:21:29] Stefanni Brasil: Average? You know, I would love to know your code coverage percentage, but also your. Uh, Skunk score average. And that way you would know a little bit more about the application. You’re getting yourself into one question I definitely would recommend to people who are considering a job is to ask the potential company, what version of rails and Ruby they’re using in production.

[00:21:55] Stefanni Brasil: In fast Ruby that I, oh, we talked to a lot of companies out there that are running like rails three to four, two, and they’ve been around for 10 years or more. Some of them are determined to upgrade and they work with us and some are okay. Just having a very old version of rails, but yeah. That is definitely like a signal to consider when accepting or rejecting a job.

[00:22:22] Thiago Araujo: Do you see any differences in the business? So for example, companies that are okay having another version of rails, are they tech companies, are they, sales companies are companies that do something that is not. Tack or maybe they don’t have a product. Do you see any differences in the mindset versus the business side of things?

[00:22:47] Thiago Araujo: How, how they do things, what they sell?

[00:22:49] Ernesto Tagwerker: Not really. I mean, we don’t specialize in any industry. If anything, we specialize on JavaScript, uh, react JS. Ruby and rails. So we’re very much tech focused and not so much industry focused. Um, we’d definitely work with companies that have from one engineer in their develop and their development team to 500 engineers in the.

[00:23:18] Ernesto Tagwerker: Engineering department, I would say it’s probably more common in smaller companies with smaller engineering teams that are focused on shipping changes, uh, patching bugs. They have a roadmap and technical debt is seen as a distraction as in, uh, we will pay off, we’ll pay it off later. Like this is not a priority.

[00:23:43] Ernesto Tagwerker: We really need to ship this for, you know, black Friday. So we’re okay. Focused on tech debt. Later, but usually later never comes anyway, but yeah, I definitely have seen a lot of these issues, not just in small companies, but also like huge companies out there. I think it’s, it’s probably like a cultural problem, like, uh, teams focusing on shipping things and the roadmap and technical debt kind of takes a back seat.

[00:24:12] Ernesto Tagwerker: And sometimes you see like these, oh, we’re going to. Uh, one or two weeks or a whole, I don’t think a whole month is reasonable, but like, let’s take two weeks, everybody working on tech debt and let’s bring it down, but once a year, and I think that’s a bad strategy. I think it’s more important to have that built-in and every sprint a little bit.

[00:24:34] Ernesto Tagwerker: So yeah, I think companies that have that embedded in their culture. Better companies to join.

[00:24:41] Thiago Araujo: One thing that Stefanni talked about about the interview thing is something that I’ve seen is sometimes. The company has, let’s say good teams and bad teams. So one of the teams, they have a good tech lead and they care about code quality and testing.

[00:24:59] Thiago Araujo: But then in other teams they don’t care as much. And so you’re like, oh, I joined the company. I interview for the steam, but then you work on another project that doesn’t really have any code coverage. So it can be misleading sometimes to ask about the code quality, because you’re never sure where you’re going to land.

[00:25:18] Thiago Araujo: Right?

[00:25:18] Ernesto Tagwerker: Yeah. I mean, I think you’re probably talking about like huge companies. I think there are also like ton of companies out there that only have one rails monoliths. Yeah. You’ll get more or better. Information. And even if you’re joining a huge company, I think you would probably be okay, asking like information about the component that you’re going to be working on, to get an idea of what version of Ruby and rails here you’re working on.

[00:25:46] Ernesto Tagwerker: I need to actually improve the way that we sell. Rails upgrade services, because I think we’re still doing a pretty bad job at communicating, like the non-technical results that you can get by upgrading. And one of them is definitely like people related, like nobody wants to work on a rails four application.

[00:26:11] Ernesto Tagwerker: Uh, nobody wants to join like a team that’s running rails three. Because every time you need to fix something, it’s like, you have to go on these archeological expedition to find the API for the current or the old version of rails. So one of the things that I mentioned in my sales calls is that if you upgrade a route six one, it’s going to be easier to hire people.

[00:26:39] Ernesto Tagwerker: And right now, you know, the market is crazy for tech talent out there. So these little things make a difference and people want to work in. Departments and applications that are not constantly on fire. Uh, people want to work 40 hours a week or less. I think tech debt is tightly coupled with the, with that idea of programmer happiness and not being a firefighter in, in your job

[00:27:09] Thiago Araujo: and not only hiring people, but also.

[00:27:11] Thiago Araujo: Keeping the goods people, right. Retention rate, because no one wants to work on an old code base for,

[00:27:20] Stefanni Brasil: I agree a lot. And also from the perspective of the majority of people that are still in the. mid-level career. You want to work on the new things. You want to keep your skills sharpening. You know, you don’t want to stay stuck working on old things because they’re probably getting stuck in your career.

[00:27:46] Stefanni Brasil: It’s going to be harder to get out of that work. And it’s really interesting how showing that in the terms of, Hey, if you don’t take this decision now, even though it doesn’t. You might not make sense. Now it’s just part of the long-term planning. That’s really clever and Ernesto, you mentioned skunk, which is the gem that you created.

[00:28:14] Stefanni Brasil: And from all thegems that we mentioned in the beginning rails_stats metric_foo ruby critic. Is this the only one that you created? Or did you also create another one?

[00:28:28] Ernesto Tagwerker: Yeah, it’s definitely the, the one I created and it has been the most popular, uh, I’ve created other gems in the past. Um, but they weren’t that popular.

[00:28:41] Ernesto Tagwerker: Um, but, uh, yeah, recently we found ourselves kind of becoming cold call maintainers of Ruby gems that have been abandoned by their previous maintainers. Uh, or you know, that the maintainers that we’re currently working on them moved onto something else. Um, so Ruby critic, um, I started contributing to it and I thought it was a really cool idea.

[00:29:06] Ernesto Tagwerker: And I started trying to fix a couple of things. And when I was building skunk, I wanted to combine complexity and churn data with, um, Code coverage. There are two great articles by one by Michael feathers, another one by Sandy Metz, where they talk about this idea of the churn versus complexity graph. And in order to find insights about a code base.

[00:29:36] Ernesto Tagwerker: Which is awesome because you can quickly see which files are the most changed and the most complex. And you’re like, okay, I probably want to stay away from, from those, if I’m just starting on the project. And then I thought it would be awesome to add a third dimension in code complexity. So instead of seeing like a 2d graph with churn and complexity, it would be more kind of like a cube, I guess.

[00:30:06] Ernesto Tagwerker: Uh, never got to build the UI for it. So right now it’s only like a terminal table that is printed and it basically ranks the files, forum, stinkiest to nicer smelling code. Um, but yeah, anyway, the idea was not to. Criticize someone’s application, but it more about finding the files that need the most attention.

[00:30:35] Ernesto Tagwerker: Um, and I thought, okay, what about combining churn times? Complexity times, lack of coverage. Um, and that’s how skunk was born. I decided to. Tightly, couple it to Ruby critic. So skunk uses Ruby critic to work. That’s why I became a maintainer, of ruby critic, uh, for rail stats. Um, so there’s, you know, the native rake stats, uh, that comes with rails, which.

[00:31:07] Ernesto Tagwerker: Pretty cool. But sometimes it’s hard when we’re trying to assess a code base and we have to bundle it and run, you know, bundle exec rake stats. It’s sometimes it’s harder than you would think because these are huge applications and not all of them use Docker. Um, but anyway, rail stats is a tool that lets you see the same statistics for a rails application without actually.

[00:31:36] Ernesto Tagwerker: Uh, having to bundle the application and start the environment. Um, and one thing that we want to do in that gem soon as combine it with bundler stats in order to get an idea of the size of our rails application and that way we would have the number of gems, number of total gems and all the statistical information on the models, views, and controllers, and then metric.

[00:32:02] Ernesto Tagwerker: I it, 10 years ago, I went to a Ruby conference in New York and I saw someone, you know, showing metric foo I thought that was really neat idea. Uh, really cool that it runs a bunch of tools against your code base. And it generates a bunch of reports, but yeah, 10 years later, I wanted to use it again because I was considering it as.

[00:32:25] Ernesto Tagwerker: Tool that I would use, uh, to create skunk, uh, on top of, um, but it wasn’t maintained. So I started making contributions and Ben, who was the last maintainer of the project was open to adding a commentator. And, um, yeah, me and my company started, uh, commentating the project recently. And if you go to the Wiki page for metric fool, you’re actually gonna find a table with.

[00:32:52] Ernesto Tagwerker: More than 30 other gems that are out there that are all about code quality. So I think the hard part about code quality is that. I would say we have way too many tools and way too many ways to define a baseline for our applications. Quality.

[00:33:12] Ernesto Tagwerker: Well is actually

[00:33:12] Thiago Araujo: pretty cool that we have so many options in the Ruby ecosystem because you should compare it to other ecosystems that they don’t have as much stuff then.

[00:33:24] Thiago Araujo: We do. Right. So it’s really interesting.

[00:33:27] Ernesto Tagwerker: Yeah, it is though, a little shocking that so many tools have been abandoned on the code quality front. I think like maybe seven years ago or seven to 10 years ago, there was a lot of focus on it. And it does feel like in the past five years, Those projects have been abandoned and there’s been no progress and many of them, yeah.

[00:33:53] Thiago Araujo: This is something that I was talking about with Stefanni, because I remember five, seven years ago, like you mentioned, there were so many projects, so many talks about good quality, good coverage and all of that. And it feels like. Things changed a bit and I’m not sure why. And then I wanted to ask you, do you have any insights into that?

[00:34:16] Thiago Araujo: Why are people not talking about code quality as much anymore? Or maybe I’m not in the right places. So I don’t know.

[00:34:26] Ernesto Tagwerker: No, I think you, you’re probably in the right place. Uh, is. I don’t think people are talking that much about it or working on it actively. I think Ruby critic is probably the best tool out there and the one that’s getting the most attention.

[00:34:42] Ernesto Tagwerker: So if, um, any of your listeners want to use one of these tools, I would recommend to try Ruby critic, um, and then maybe skunk, you know, The barrier of entry for skunk is a little higher because you need to runsimple cov first and then you can run skunk. But yeah. Going back to your question, I don’t know why people are not actively working on this that much and why there isn’t that much content about code quality and Ruby anymore.

[00:35:16] Ernesto Tagwerker: Hopefully it is because people are using tools. Cold climate and code scene. And maybe they’re just adopting the defaults that are in those tools. Which is okay. You know, like if you want to use those tools, that is awesome. Go for it. They will help you pay off technical debt and focus on having a measurable, measurable way to do it.

[00:35:43] Ernesto Tagwerker: I think maybe the quality, the quality department or the quality area has been more reactive than proactive for many companies. So it’s like. Oh, performance started crawling like what’s what’s going on. Okay. We need to find bottlenecks. Okay. Let’s focus on performance now. Or. You know, oh, the developers are taking too long to ship stuff because the code is a huge mess.

[00:36:10] Ernesto Tagwerker: Oh, okay. Let’s spend a four spreads trying to pay off technical debt and then that will fix it. Um, which is, as I said, like a bad idea. Um, but yeah, I think we are very much reactive as, as an industry and I think. Maybe we need to be a bit more proactive. Um, and if you don’t want to use code climate or code scene, you can adapt some of these tools.

[00:36:40] Ernesto Tagwerker: I know, like there are certain tools that are very much up to date and adopted, like Robocop is adopted and as a great way to make sure. You know, how silly discussions about code style in a pull request. You just have rural Robocop and Robocop takes care of it. Um, standard is, you know, another take on Robocop.

[00:37:01] Ernesto Tagwerker: I still like based on Robocop and then there are other tools. So some people also like to use things like reek, uh, that will basically run with over commit. So every time someone tries to commit a code. Is stinky, according to wreak, they will have that in place. Um, so I think maybe it’s because people are picking like one or two tools and just applying them to their.

[00:37:29] Ernesto Tagwerker: To their checks for every pull request.

[00:37:32] Stefanni Brasil: That would be really cool. Maybe that is one of the scenarios, hopefully. And I still, you already mentioned the gems again, and I would like to ask you as a community, how can we support. Better your, I know that the best way is to contribute more, but is that, is there something specific, like maybe, do you need people to just use it now and give you feedback?

[00:38:02] Stefanni Brasil: How, how can we help? The community by supporting the gemsthat you’ve maintained.

[00:38:08] Ernesto Tagwerker: Yeah. Uh, I think using some of these gems would be amazing. Um, yeah, like you said, contributing can sometimes take a long time and can be a little scary, but, um, trying to use it, trying to use any of these tools, like metric food, um, rail stats, um, Ruby critic and skunk, uh, would it be.

[00:38:33] Ernesto Tagwerker: Awesome because. If you find any issues, then we can quickly assess why it’s happening and try to fix it. Um, another thing that you can do is if you run skunk, um, there’s a little environment variable that you can set, uh, like it’s called share. She said share to one and you run skunk on an open source project.

[00:39:00] Ernesto Tagwerker: Uh, and then it reports back to a little service that. That’s also open source. It’s called it’s called, um, skunk FYI. Um, that gives us more information to work on version 1.0, uh, I think for ver version 1.0 of skunk, what we want to do is change the skunk score grading system to something that’s easier to understand.

[00:39:28] Ernesto Tagwerker: So. It seems like the grade a to grade F is the way to go. Like Ruby critic, does it cold climate does it. And I think skunk should do it too so that when people run the tool, they can see, you know, oh, this is an, a, this is an F there’s a D and it’s easier to. I understand that the information that’s throwing at you, because some right now when you run it, it says like all the skunk score for this file is 15,000.

[00:40:02] Ernesto Tagwerker: And one of the questions that I’ve gotten at conferences is like, what does that even mean? What is 15,000 good or bad? And I want to give more context and say like, yeah, 15,000 is probably bad. So. Please, uh, considering factoring it.

[00:40:20] Stefanni Brasil: I’m curious to know, how did you get started with contributing to open source?

[00:40:26] Stefanni Brasil: Do you remember the first one and how was it?

[00:40:31] Ernesto Tagwerker: Uh, yeah, for sure. Um, the first project was a Ruby wrapper for a service called topsy and. They were acquired by apple many years ago, but, uh, I really liked the idea of building wrappers and Ruby for API APIs. And I worked for about a week and our released it.

[00:40:54] Ernesto Tagwerker: And then a week went by and someone else wrote the same gem and released it. And I was like, oh, What a bummer. Someone just did the same thing that I did, but they did it better because they added a test suite to the project and. Uh, yeah, it was a bummer at the beginning, but then I reached out to them on Twitter.

[00:41:18] Ernesto Tagwerker: And to, to this, to this day, I can say that we’re friends thanks to open source. So anyway, if you want to get started with open source and you know, an API, that’s cool. And you want to use it to do some sort of mashup. I think that’s also like a great way. To get started with, uh, open source because Ruby wrappers are pretty easy to write.

[00:41:45] Ernesto Tagwerker: And there are a ton of examples in github. Like you can just search for like the Twitter API, Ruby wrapper, and you can just copy and paste a lot of the code in there to create your own wrapper. Um, but yeah, I, uh, anyway, I, I love open source and for 10 years I’ve been doing this and. I know it’s hard for people who are just starting.

[00:42:11] Ernesto Tagwerker: So I think using the tools and reporting back, any issues that you have is a great way to get started, to contribute to source. And another way to get started is if you like one of these tools and you want to run or write up tutorial or your own experience running one of these tools and what you learned with them.

[00:42:34] Ernesto Tagwerker: You know, you can create an article and that helps us get more eyeballs and more people using the tools and hopefully the eyeballs turn into more issues as well.

[00:42:47] Stefanni Brasil: Uh, good advice. One thing that pretty surprised us when we. Decided to just explore rails was we didn’t set a lot of expectations. We, we got there just, okay, what can we do here?

[00:43:05] Stefanni Brasil: We learned quite a few interesting things just by trying to reproduce issues. For example, I think that starting with a project, just as a way to explore and setting your expectations really low kind of help. Cause then you discover some things and you makes things more exciting, I guess.

[00:43:30] Ernesto Tagwerker: You know, some people wouldn’t recommend, uh, new developers or junior developers to start contributing to rails because rails is a beast and, you know, it’s amazing.

[00:43:44] Ernesto Tagwerker: I love rails and I love everybody contributing to it. But. It’s very hard to get started with something there. That is, code-based one thing that you can do, and I’ve actually done it. Myself is go through the documentation and improve the documentation. There’s so much room for improvement in their rails docs that, um, if you want to make like a tiny contribution to rails, that could be a good way to get.

[00:44:14] Ernesto Tagwerker: Um, and the more you look at the documentation, the easier it’s going to get to eventually make a code contribution to rails still. I would not recommend people start with rails. I would recommend they start with a. Small gem that they might be using or, uh, yeah. So something that’s small and easy to understand.

[00:44:39] Thiago Araujo: Yeah, that’s a great, great tip. One thing that I guess was Gui friend of ours. He came on a podcast long time ago. He said, if you want to contribute, maybe use, maybe just get a gem. And then use the latest rails version, you know, rails 7.1 batter or whatever, and then see if it breaks if the test suite breaks and then you can just fix it.

[00:45:04] Thiago Araujo: So this is kind of a easy way to contribute to other projects because the API, the rails API changes. So it’s. Keep things up to date.

[00:45:15] Ernesto Tagwerker: Yeah. Yeah. I love that idea. And I’ve actually implemented it myself on these, some of these tools, that’s kind of how I got involved in some of them, because I wanted to see if they work with Ruby three and you know, Ruby three, it’s almost been a year, but there are many libraries out there that are not running their test suite against Ruby three.

[00:45:39] Ernesto Tagwerker: And. There’s certainly a great way to, to find issues with a gym. And even if you don’t find an issue, you can just submit a pull request, including Ruby configuration. And it’s just telling them like, Hey, you were missing. gem works with Ruby three of, and it’s like a very quick way to make a contribution.

[00:46:04] Thiago Araujo: So just getting back to the code quality discussion, I’m kind of fascinated by legacy applications, because at the same time that people originally angry at legacy code, you know, they say, oh, it’s terrible is all crap and all of that. But at the same time, It’s usually a sign that people are using the product, which is something that is very valuable for a company to have people actively paying and using yourself.

[00:46:38] Thiago Araujo: And then people are very negative about legacy applications. And I, I think that the tips that you are sharing and then using these tools and, you know, learning more about these techniques from Michael feathers and Sandi Metz can help you be more positive about working with legacy code because you’re contributing to something that helps.

[00:47:04] Thiago Araujo: You kind of have to change your mindset about legacy code. Right. Did you ever have to change your mindset about something that you see like a sequel in a positive way? How do you kind of approach that?

[00:47:19] Ernesto Tagwerker: Yeah, I agree with you. Like their legacy code gets a bad rap. You know, if you think about it, um, Shopify is running legacy code and they’re making millions of dollars and sure.

[00:47:36] Ernesto Tagwerker: They’re running the latest of rails and Ruby, but, um, yeah, if you think about it, it’s been, uh, if an application has been around for 10 years and there’s a whole company counting on it, It is deemed to be legacy code. To me, it just means like this is a business that works. And at the end of the day, they can pay me to, um, have a salary, basically.

[00:48:01] Ernesto Tagwerker: So, and I can use the time that they pay me for to, to make it better. I really like this idea of makers and menders. My friend am Scott Ford, who runs another podcasts. I think it’s called legacy code rocks. He likes to talk about the idea that, you know, engineer. Usually are either makers or menders and either you like to build something from scratch, or you like to mend something that already exists.

[00:48:34] Ernesto Tagwerker: I’m more of a mender than a maker. I’m sure I built my company. So in a way, I like to make businesses in a way, but some people in my company are more makers than menders. So what we want to do in my company is to have. Projects for makers and for menders. Um, but if I had to pick myself, I would pick the mender projects because I like to gradually improve, you know, the infrastructure of an application or to improve their processes.

[00:49:11] Ernesto Tagwerker: So. Yeah, I think, uh, I think it’s important to make that definition between, you know, what you want to do with your career and what they want you to do at work, you know, and sometimes, you know, you’ll just want to mend things and sometimes. You know, other people will just want to make things and that’s okay.

[00:49:33] Ernesto Tagwerker: Um, what I like about legacy code is that it’s working and it’s been working for many, many years and sure it can be enhanced and improved. There’s probably a test suite and the test suite is going to tell me I changed something and I try to pay off technical debt and I broke it. So yeah, I really like legacy code.

[00:49:55] Ernesto Tagwerker: Yeah. I know there are a ton of people out there that love to work on legacy code too, even when it gets up.

[00:50:02] Thiago Araujo: But it’s funny because it don’t hear much about it. So there are people out there working on legacy code, making things better, and you don’t hear about it because it’s working. Right. So it’s kind of like you’re doing important work, but maybe you don’t get as much.

[00:50:19] Thiago Araujo: visibility when you’re doing that.

[00:50:21] Ernesto Tagwerker: Yeah, I guess it’s, it’s definitely not sexy. Like, it’s not like, oh, I built this, uh, JavaScript framework to, you know, solve this problem. It’s no, it’s definitely not, not sexy. And maybe if people write about it, Reaches, not that that big, but there’s definitely like a microcosm of people who are writing articles about legacy code and maintainability.

[00:50:52] Ernesto Tagwerker: Yeah. I actually love to be in that little microcosm, I guess

[00:50:58] Thiago Araujo: I really loved the analogy that you mentioned Manders versus makers. And I think when you’re getting. Um, maker an engineer who is a maker and tells this person to mend software. I think the knee jerk reaction they have is, oh, I’m gonna throw everything away and build everything from scratch, you know, the big rewrite and things like that.

[00:51:24] Thiago Araujo: And it’s. Usually doomed to failure, right? So maybe you can’t do that. So don’t put a maker to mendyour projects.

[00:51:34] Ernesto Tagwerker: Uh, well, there’s this book by Fred Brooks and I think it was published in the seventies. And one of the chapters of the medic mythical man month is called something. The joys and woos of the craft.

[00:51:48] Ernesto Tagwerker: And he actually goes on to say like, yeah, you know, like building something is like accessing, like the creative part of your brain is like, that’s full of joy because you’re like in a state of flow, you’re trying to solve a problem and you’re trying to build something new. So it was like, oh, everybody’s joy there.

[00:52:06] Ernesto Tagwerker: And then the woos, or like the, the bad part is like fixing bucks, you know? And he assumes that nobody likes to fix bugs. I think that’s a wrong assumption. Like I think there are like, uh, many people out there that love to solve puzzles and love to basically dig into a bug and go deep into. The stack race and try to find that anyway, I think like we need to add this to our lingo and to say, just because you’re a software engineer doesn’t mean that you enjoy building stuff, stuff from scratch.

[00:52:42] Ernesto Tagwerker: Like there are plenty of software engineers that just want to go to an established team and maybe. Improves that code base to work better for the end user or the developers.

[00:52:54] Stefanni Brasil: I know rnesto. So you will have lots of things you do. Uh, just want to try to ask if there is something that you would like us to have asked that we didn’t

[00:53:03] Ernesto Tagwerker: well, yeah, considering you’re from Brazil and I’m from Argentina.

[00:53:07] Ernesto Tagwerker: I was actually expecting, we could talk a little bit more about soccer and the America’s cup and the last final that Brazil and Argentina played, but I know. Topic. It’s not the topic we’re discussing today, but, um, I have time to discuss that if you want. Thank you.

[00:53:25] Thiago Araujo: We were probably the worst people. This, I have no idea about soccer at all.

[00:53:35] Thiago Araujo: I don’t really watch soccer. Sorry.

[00:53:38] Ernesto Tagwerker: Okay. Yeah. Even if you knew, uh, I would expect that answer anyway, so no worries. Carnival soccer. We are not very into that kind of stuff, but we can talk about food. So food is our passion. Okay. Okay. Um, anyway, no, it was great to be here. And, uh, yeah. If anybody wants to see some of the work that we do, uh, feel free to follow me on Twitter.

[00:54:08] Ernesto Tagwerker: My handle is etagwerker and I usually. Uh, content from the company.

[00:54:15] Stefanni Brasil: Thank you so much. That was a great talk. I loved learning so much things from you. So thank you so much for sharing your experience and your skills and insights. You know, we will make sure to put the gems in the. Episode notes. So everyone can at least take a look.

[00:54:36] Stefanni Brasil: Ernesto is a really nice guy. And you can say you, you met him from the podcast. Everyone go check them.

[00:54:43] Thiago Araujo: Yeah. Thank you so much. Thanks so much here,Ernesto for coming on the show. Thank you so much for your work as well. So these gems are really important and, you know, having someone to take over and continue the work is really important, really relevant.

[00:54:59] Thiago Araujo: The community is also nice to finally meet you because we worked in the same projects in the past. We will never really met. I always saw your picture on git but I never got to talk to you. So it’s really amazing to, to meet you and thank you so much.

[00:55:15] Ernesto Tagwerker: I hope it’s all, all good things and you didn’t have to fix all the bugs that I added before I left.

[00:55:23] Stefanni Brasil: Yeah, should run the skunk and report.

[00:55:30] Ernesto Tagwerker: Please do that.

[00:55:43] Stefanni Brasil: Thank you for listening to this episode, we put lots of love into the hex labs podcast, and we hope you learned something insightful before you go on with your day. Could you share this episode with a friend or a colleague? That would help us a lot

[00:55:58] Thiago Araujo: And don’t forget to subscribe to our newsletter, to get exercises, tools, insights, to help you become a Ruby expert developer. See you on the next episode.

Did you enjoy this episode? Then check out the How to Improve Code Quality on a Ruby on Rails Application guide.