274. Why Code Quality Is Not The Most Important Metric

Why doesn't my manager focus on code quality? Why are we constantly rushing to get things done instead of fixing our bad code? Why don't we follow the best practices at work? These are the questions we will answer in today's episode of Dev Questions.

Website: https://www.DevForge.com/ 
Ask Your Question: https://suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: https://signup.iamtimcorey.com/

Transcript

Copy Transcript Copied

SPEAKER_01 0:00

Code quality would seem like the best thing to focus on. Following best practices, applying design patterns appropriately, and generally writing well-structured code seems like a good thing. But code quality is actually not the most important metric a company should be focusing on when building an application. So let's talk about why code quality shouldn't be the primary focus for businesses building software in today's episode of DevQuestions.

SPEAKER_00 0:37

Welcome to the DevQuesti podcast with Tim Corey.

SPEAKER_01 0:41

Software development is more than just writing code. So let's talk about the rest of it. Specifically, let's talk about the primary focus of business applications and why it isn't code quality. Code quality is important. And in this episode, we're going to talk about how to make sure that it's still valued. But let's first talk about the primary focus of business applications. To do that, I'm going to ask you a question. The question is this: why does an application exist? Let's make this clear. Let's say you work at Acme Corp and you're building a warehouse management application. Why does that application exist? Applications exist to perform a task. Just like cars exist to transport us where we need to go. So what is the primary purpose of applications? To get the job done. And that's where the tension comes in. So this is the tension between what we want to do and what we need to do. So getting a job done can mean pushing to production before you're ready. One of the things that people often want to do is just a few more days, a few more weeks. If you follow game development, you know, this is one of those things where game development is kind of out in the open, meaning they announce well ahead of time we're going to build this game. And you might think of a game like uh Grand Theft Auto 6, which has been in production for I think 10 years. Um, and it's always just around the corner. Well, actually, that corner is a little farther away. This happens all the time. And part of this is you know, mismanagement. Part of it is management wanting to change directions halfway through. I get that, but a big part of it as well is people want to make things that are great. They want to add a little more polish, a little more finishing touches. I want to make the code a little better. And so what happens is you push off a deadline and push off a deadline and push off a deadline because you want to make it perfect. But here is the deal. When you do that, you deny the ability to use that application for that many more days, weeks, months, it can turn into years. So what happens? What's the primary purpose of the application? To get the job done. The job's not getting done because you didn't push to production. So pushing to production is sometimes needed, you need to do it even before you feel ready. In fact, the first version of your application really should go to production well before you feel ready. Now, getting the job done can also mean adding a feature instead of improving code quality. This is hard because when you work at a company and you look at the code base and you know the code base is messy, and you know that if you just put some work in, you can make it better and you can make it a long-term better solution. This happens a lot with even upgrading the application, where you're on.NET 5 and you know, like, man, we're out of support. We need to upgrade a.NET 9. I know it's it's mostly just a couple of changes, but I need to get it done. But that's not the priority of the company. And sometimes it feels like they just don't understand. And to an extent, no, they don't, and you need to help them with that. But part of it is you don't understand because the whole goal of your application is not to have a perfect application. The goal of the application isn't to have the most efficient application. The goal of the application is to get the job done, and they need that thing done. So they need that new feature over what you think is more important, code quality or performance improvements or tweaking how you do something. So getting the job done can mean adding a new feature instead of improving code quality. Now, getting the job done can also mean implementing a workaround instead of getting the taking the time to design an elegant solution. I don't know how many times I have created a quick workaround that ended up in production. Because you know what? At the end of the day, maybe taking five minutes and putting some messy code in there that works is better than spending half a day or a day tweaking it and making sure that it's it's architected right and having a discussion over how it should be architected and what can be changed, et cetera. Sometimes you just need to get something into production. And that workaround, yes, it's going to add technical debt. And that debt is going to have to be paid at some point. But sometimes it's worth it to take on a little tech debt in order to get something out into production. Getting a job, getting the job done can mean bypassing code reviews and other safety checks. This is not one you should do very often. But sometimes you need to rush things into production. Sometimes you need to rush past a normally uh calm process of reviewing the code and verifying everything works and maybe even having a multi-stage deployment where you deploy it to first the development servers and test it there, and then deploy it to a staging server, then a QA server, then a pre-production server, and then you know the canary build, and then you have the slow rollout. Sometimes you don't have time for that. Sometimes you need to bypass a lot of those steps and say, we're gonna get close enough. Because sometimes you need to get something into production in order to meet meet a new sale that's coming on. Um you need to get something into production because there's a bug that just needs to get fixed. You sometimes need to get things into production because the boss is gonna be checking on something, or the CEO is gonna be checking on something, and you need to have something new in place. And you know, that feels sometimes arbitrary, it feels sometimes frustrating, but sometimes that's what need to happen needs to happen in order to get things done. And that sometimes means shrinking your code review and other safety checks, not totally eliminating them, but shrinking them or compressing them. Getting the job done can mean rushing changes in order to meet the deadline. I have this kind of comes back to that deadline thing, that the idea of pushing the production before you're ready. Sometimes it feels like your boss gives you an arbitrary deadline. They say, you know what, we're gonna have this done by October 1st. And you're like, it's already the middle of September, and I have a month and a half worth of work to do. The boss says, I need you to have it done October 1st. And so sometimes you rush changes, and that might mean doing workarounds. It might mean bypassing some of the full review process you have. It might mean, you know, figure out how to just throw code in there and get it to work rather than making it perfect. So that can happen. But you know what? You're meeting a deadline, it's not always just about you. And this is kind of the whole idea behind this is being a software developer, we we create things, we build things, we we architect things, we think that we know best. And in our world, sometimes we do. But we have to remember that we are just a piece. And in fact, we're the supporting piece of most every organization. We are not the front line. We are not the reason the organization exists in most cases. So we need to figure out how to support them better. And sometimes that means rushing to meet a deadline. Getting a job done can mean copying and pasting code from other locations, violating dry like crazy. And again, why does dry exist? Because it reduces errors, it reduces potential errors. But sometimes you just need to get it done. And you just need to say, you know what? I know we have this in the project over here. Let's not worry about creating a NuGet package and extracting out and getting all that set up. Let's just copy, paste, done. It works. And it working is more important than it being perfect. Okay, getting the job done can mean not writing unit tests. It can also mean not documenting the changes. I just um encountered this today where I'm busy, I've got a lot of stuff to do. In fact, I'm getting ready to head on out for a conference and then vacation. And so I'm trying to get a lot of stuff done in a little bit of time. And in the middle of it, our internal admin dashboard went down. I had to get it back up because we have things coming, we have new courses coming out, we have stuff to do. So, what did I do? Well, I got the job done and I found out it was an expired uh secret. And so I renewed the secret. But you know what I didn't do? I didn't document the process. I could have. I could have spent the time, but you know what? I didn't have the time. I decided it's okay. When that comes back up next year, I'll just figure it out then. And that's okay. It's pushing off work for next year. And yes, it will make more work for me next year than I otherwise would have, but I just didn't have time to document and figure out where I'll put that documentation and make sure that it was in my notes and would come up in my calendar and all the rest of stuff. I didn't have time for that because I had more important priorities. This is all about understanding priorities. And sometimes, most of the time, priorities aren't going to align well with perfect code, which is why every application in the world is ugly and messy. It just is what it is, because not everything aligns with being perfect. So all of these things can be true and can be justified. The longer you work in software development, the more you will have participated in them firsthand. These are all situations you want to avoid, and I'm not advocating that you do any of them without cause. But there's an argument for all of them being the right choice depending on the circumstances. So, does that mean we give up on code quality? Absolutely not. We just have to remember that it isn't the top priority. That means that we have to be better about meeting the top priority while also including code quality. The more code you write, the better you will be at writing more maintainable code the first time and quickly. That in turn will allow you to meet the priorities of getting the job done while still producing high quality results. So this is something that comes out. Uh if you are familiar with the guy named Mike Rowe, he is a really big advocate for the trade. So electricians, plumbers, etc. And one of the things that he pushes back on is the idea of companies and organizations saying, safety first. And he says, no, it's not. And you say, well, wait a minute. No, no, we have to put safety first because our employees matter. And his argument is safety isn't first, because otherwise you wouldn't do anything. An electrician deals with scary amounts of power. And the most safe thing to do would be to not deal with scary amounts of power. But they can't. That's part of their job. So while safety is important, it's not first because getting a job done is first. That doesn't mean you don't be safe. Very much you want to be safe, but it's not the first thing. And the same thing is true with code quality. It's very important, but it's not first. So the bottom line is this: don't elevate code quality above shipping. Instead, try to ship the best possible code by improving your skills as a developer. Some of the most successful games, movies, books, and applications have been a result of intense pressure to ship quickly. I want you to look at books like the uh the book about Doom and the building of that game and how there was such intense pressure around you have to ship now. And by the way, you're shipping other games at the same time. And they created some really important lasting art because of the fact that they had that intense pressure. And then you look at other situations where maybe a movie director was given full license and a huge budget and said, just go build something. And they turn out junk, even though they had been very successful in the past. And what was the difference? In the past, they had tight budget constraints. The original Star Wars, if you ever watched the making of Star Wars episode for A New Hope, it's fascinating stuff. But one of the things that that led to the success it had was the fact that they had extreme limitations. They wanted to do this amazing things, and they did, but they didn't have great computers. They didn't have these great CGI systems, they had to build these things, they had to build practical models with a very low budget. And even after they succeeded in the first one, they had to finance the second one by hand because of the fact that people weren't sure they wanted to have a sequel. And yet Empire was one of the most successful ones out that came about. So that intense pressure created some great movies. Now you could argue that following that, the blank check of the new movies kind of caused them to struggle because the fact that there were this kind of almost a blank check on do whatever you want, make the best movie possible. And what it comes down to, you find out, is the best movie possible is often made under the most intense pressure. So some of the greatest failures in all these categories, uh gaming and applications and movies and books, some of the greatest failures in those same categories were made by people who prioritized perfection over getting the job done. Get the job done. Thanks for listening. And as always, I am Tim Corey.

SPEAKER_00 16:08

Thank you for joining us for this episode of Dev Questions. When you're ready to learn to think and code like a professional developer, head over to IamTimCorey.com and enroll in a course.