Ditching Hourly

Hello and welcome to Ditching Hourly. I'm Jonathan Stark. Today I've got an audio excerpt from an answer I provided on my YouTube channel. You can check it out at thejonathanstarkshow.com and it'll redirect you to YouTube if you're into watching videos. Otherwise, you can just listen to the audio here on the podcast. Enjoy. Hey, Jonathan here. Got a question from Kevin Smith who asks, It seems like it would be tough to value price something like fixing code quality in an application. Would you recommend using tools that measure code quality as proxy for achieving the client's biz goals of increased revenue, customer retention, etc.? Okay, so there's a couple of different angles here. It sounds a little bit like Kevin is looking, you know, as a hammer, looking for a nail, you know, like he's really into, you know, decreasing technical debt. And as a software developer, all the software developers know that technical debt is a bad thing. But sometimes debt isn't a bad thing. Sometimes because of timing or whatever, sometimes it makes sense to take on debt, just like financial debt. Sometimes it makes sense. Is it often a bad thing? Yeah, it's often a bad thing. But sometimes it makes sense. So first I would say, and maybe that's not what Kevin's saying, maybe he's just picking an example, but it's very tactical, the example that he picked. So let's just say it's, so the first thing I would say is I wouldn't worry about surfacing that too much to the client. You know, unless they came to you and said, we really need to improve the code quality of our application. You know, for someone who's a developer, when they hear that, they're like, and they look at the code base, and it's a massive spaghetti PHP from like 1993. You'll be like, yeah, you do. This is awful. You know, but you have to, it's easy to quickly agree with them. But the problem that's going on is you haven't yet found out exactly why they care. They're not developers. They don't care because they look at it and they say like, man, I can't believe those like inline CSS styles and table-based layouts. Like they're not looking at that. They're not seeing the same thing you're seeing when you look at it. They're probably not even looking at the code base. They probably can't even read it. It might as well be Greek, but they're having some problem that someone told them is because of the code quality. Or maybe they know they cheaped out and they just like, they just spent as little as they possibly could and they got garbage back. And so you still want to push back. You want to find out in their words why they want the code quality fixed, even though you know it should be fixed. It's important to get them to say it because you want to know what they're going to judge the success of the project on because they don't understand the code. They're not going to look at your shiny new repo of perfect code, like pristine, elegant code, and just be able to look at it and be like, wow, that's beautiful. They're not going to do that. They're going to look at something else like, oh, wow, we haven't had any bug reports in six months. That's amazing. So you want to find that out. So even if someone told them that, you know, the code quality is bad and they need to find an expert on Rails or whatever you write and they need to fix the code quality, maybe even need to rewrite from scratch, push back like crazy. This is what the why conversation is for. Get them to tell you why. Why? Like, yes, we can both sit here as adults and say that your code is a mess and that's a problem. But in your own words, dear prospective client, what problems, what business problems is it creating for you? And drill in and drill in and drill in and drill in until a six-year-old could understand what the problem, you know, that it's bad. And you might find out as you go through this whole thing when they say, you know, X, Y, and Z, these are the things that are problems like our customer churn is crazy because we're releasing bugs to production every single week or we're releasing bugs. You know, we're only releasing once every six months and there's tons of bugs every time and clients are just like, oh, get me out of here. I can't stand this. I'm trying to run my business on this piece of junk. So maybe it's customer churn. So then if you think, okay, maybe you're a code quality expert, but if what they really need is a quick fix for customer retention, maybe there's something you can do short of the complete rewrite that it needs that will actually move the needle for them for customer retention. So maybe once you understand their desired business outcomes, maybe you say, well, let's do this. We could do this in phases. We could do a quick and dirty thing where we, you know, set up a continuous delivery pipeline. So at least you're releasing every two weeks instead of every six months. So we'll catch, there'll be fewer bugs because it's not this massive release and we'll catch them more quickly by, you know, because it's just a fewer number of features. So it'll feel like tiny little bugs. It'll be more like not everybody's having some different bug. They'll just be little ones that affect smaller numbers of users. Maybe. I'm just making stuff up here. But the idea is if you know that the problem is all these bugs are getting into production and...

churning like crazy and we're not releasing features fast enough and that's causing people to be dissatisfied. There can be easier ways to solve that problem. So maybe if you give them three options to solve this, maybe the first option is a Band-Aid or a tourniquet to stop the bleeding. You know, like, okay, here's what we can do. We'll just start writing automated tests like crazy or maybe the code quality is so bad they can't do that. Okay, we're going to implement continuous delivery so at least we can have smaller releases and therefore a smaller number of bugs. Or you could say, well, we'll just release to smaller parts of the user base so they'll be doing testing for us and we can fix it and then do a general release. You know, these are all maybe bad ideas, maybe good ideas, but the point is, I'm not saying you're doing this, but try hard not to be like, I'm a code quality expert and that's my hammer and I'm going to go around making code better because the client doesn't recognize good code from bad code by looking at it. They recognize good code from bad code by the fact that they're losing customers. And if you can help them stop losing customers, they will write you checks. So, you know, maybe the air quotes ideal solution of rewriting the whole thing from scratch with like the most modern continuous integration and WebKit and Webpack or whatever this stuff's called. I can't even keep up with it myself. Maybe that's option three, but maybe there's an option two that isn't quite as thorough and maybe there's an option one that's just a tourniquet to stop the bleeding. And then maybe you move up to option two later or a second phase or something like that. So, is it tough to value price? Well, value pricing is kind of hard always, but if you think of it the way I just described, focusing on churn or whatever the customer sees as the problem, the symptom. So, here's another way to put it. Bad code is a disease. The client sees the symptom. The client is not seeing the underlying disease. Somebody might have told them that's the problem, so they're kind of looking for it, but you still need to know what symptoms they have because if those symptoms don't go away, they're not going to care how elegant your code is. Okay, I'll stop there. All right, I'm Jonathan Stark. If you have a question for me, hashtag AskJonathan on YouTube, LinkedIn, or Twitter, and we'll add it to the queue. Bye. Would you like to learn how to get paid what you're worth? How about selling your expertise and not your labor? We work through all of this together in the Pricing Seminar. Pre-registration starts soon, and you can sign up to be the first to know when early bird pricing is announced at ThePricingSeminar.com. That URL again is ThePricingSeminar.com. Hope to see you there. Hey, Jonathan again. Do you have questions about how to improve your business? Things like value pricing your work instead of billing for your time, or positioning yourself as the go-to person in your space, or maybe productizing your services so you never have to have another awkward sales call or spend hours writing another custom proposal. Book a one-on-one coaching call with me and get answers to these questions and others in the time it takes you to get ready for work in the morning. Best of all, you're covered by my 100% satisfaction guarantee. If at the end of the call you don't feel like it was worth it, just say the word and I'll refund your purchase in full. To book your one-on-one coaching call, go to JonathanStark.com slash call, C-A-L-L. That URL again is JonathanStark.com slash call. Hope to see you there.