Don't Fix What's Not Broken - How Should Developers Think About This?

Transcript is auto-generated and may contain errors.

Hey folks, I'm just leaving CrossFit here and we're going to Experience Dev's subreddit for a topic. This one is someone's struggling with some feedback around don't fix what's not broken. And um they don't seem to offer really specific details in their post, but they do say that they've been trying to pitch ideas to management. they've been trying to pitch ideas to senior engineers on the team and um the feedback is pretty consistent. So like not just from like management management or business people uh but and again I don't know these exact roles by the way um but not just that it's also like other engineers so they're like they kind of acknowledge like look I get it like there's risk associated with things but uh they're kind of saying like it feels like my career is like stagnating if I have to sit here and

I can't do anything and uh I thought this would be interesting to talk to Um because I I think that this is a I don't know like a common misconception in software development and we don't have a lot of detail in the post so it's not fair for me to like sit here and like try to you know criticize or pick apart what this person is saying cuz I just I just don't know the reality of their situation. But I think we can kind of step back and it at it step back from it and look at it more generically and um the the meta point that I want to talk through in this conversation is really like um is thinking about like selling and when I say selling I mean how you're going to communicate value to different target audiences. And I use the word selling in this case because uh sure you're not like exchanging something for money.

But um what you are doing is getting someone to buy into your idea. Okay. And the whole principle behind this is like there's different people that have different goals in mind. Now at a company like you're all like if the company has you know good culture, clear vision and you know core values this kind of stuff like hopefully everyone at the company is aligned in general right like there's some customer base that you're serving. your company's on a mission to address some pain point for some target audience people rally behind this in the company but the different groups within the organization have different priorities within that to address that right I'm speaking in huge generalizations here but please bear with me um so you know the typical one that I always go back to is you know engineers uh so like people who love to program what do we want to do we want to address the tech debt, right?

We want the code to be beautiful. We want to spend time doing that. And stereotypically, our product managers don't want us to ever spend time on tech debt. We got to go shipping features. And by the way, all those bugs somehow get those fixed, too. We don't care. Like, ship it by tomorrow. Let's go. Uh, right. I'm obviously exaggerating here, but this, you know, stereotypical dichotomy we have between people who program and people who prioritize uh value to users. And truly like we we have the same goal. It's that's why I'm trying to give you this kind of like silly sounding example. We have the same goal. We want to deliver value to customers, but the steps that we're trying to take in order to get there look different, right? where you know stereotypically engineers want to focus more on like how do we get this cleaned up?

How do we make it so that we can build effectively here so that we can deliver value? And stereotypically, you know, product managers don't give a They just want, you know, or like if you factor in like sales people, sales people have already promised to customers the stuff that doesn't exist. Again, speaking in sweeping generalizations here to exaggerate it, but I think you get what I'm saying. So, in this case that this person's writing about, I suspect that they're probably struggling with like identifying value and communicating value. One of the two at least. Okay. So, what do I mean by that? Well, they're talking about they want to innovate. They they're pitching these ideas and they're getting the feedback like don't broke or don't don't try to fix what's not broken. I can't even speak properly.

So, to me, that suggests that what whatever they're trying to pitch, cuz I don't really know what they're trying to pitch, but whatever it happens to be, it's being perceived as like you're coming up with a fix for something that isn't actually a problem. And you know, the the way to to summarize that is like I don't see value in what you're proposing. So you are in this case like unfortunately failing to communicate some value to a stakeholder. And what's really interesting in this example is like you have two different target audiences, right? You have someone who is also a software engineer like and it sounds like multiple who are like no like you're you're basically proposing something that just sounds like work to do but not actually solving a problem. And you have people in management who are responsible for prioritizing other work who are also saying like that that's not adding value.

Now here's the tricky part. um what's being proposed might be adding a ton of value maybe, but perhaps what's being communicated is really failing to convey that message to two different groups of people, which I find like kind of surprising cuz usually in my experience, you'll get one of these two groups to go, "Oh yeah, right. We're going to we're going to go redesign this part." And that's going to clean up the code base. Just making up a stupid example. All the managers and the product managers are like, "We don't care. Like, what value is that to us?" And all the programmers go, "Hell yeah, like that's a painoint for us. Let's get it fixed up." Right? So, you get like one of these sides bought in.

I'm making really dumb examples here just to kind of illustrate uh a point, but um you know the idea being that these are two generally like groups of people that that prioritize different things and uh seemingly this person's not getting their their proposals to land with either. So, I feel like it's either that what they're proposing genuinely is not genuinely not solving a problem or it is and they're doing uh unfortunately a poor job in communicating that. I think that there's um potentially confusion like again we don't know what this person is proposing but I suspect that there's some type of confusion with like you know, modernize something or change some tech stack or, you know, different architecture and like that that might sound interesting or sound innovative or sound like change, but like what is what problem genuinely is actually being solved by doing that?

And I don't I'm not asking that in like a facicious way suggesting there isn't but like what is it? Um you know you'll hear hear people talk about rewrites of things like what problem are you actually solving by rewriting something? A rewrite's like the most extreme example, right? You're literally saying, "We're going to take this thing that's already working and forget about it and start from scratch because clearly this thing's so far off the rails or this other approach promises so much value that it's literally worth it for us to scrap this one and go with a new one. Not invest any further into this." That's why it's extreme to to do rewrites. But a lot of the time, you know, people won't see that and they're like, "Well, it looks shinier and clearly we can, you know, if we rewrite it from scratch, we can avoid all of the problems." Like, yeah, good luck.

And this is what famous last words from everyone who's tried to rewrite something from scratch. You just get different problems. Um, so when you're trying to make proposals like this, like what what are you actually trying to solve? And you might know, but like you should have a goal in mind when you're doing this. So to give you an example, um like the where where I work on the team I'm on before I joined the team, they talked they did a rewrite of one of their services and like why would you go rewrite it? You already have a working version of it. well, doing incremental improvements and trying to squeeze performance out of something, they were reaching limitations. They had coupling that they wanted to make sure that they could move away from. There's a a list of things architecturally where they're limited and there were business reasons for doing so.

Literally, business reasons where they could say, "If we can move to this, we can actually get a large amount of additional throughput But what does that mean? Like who cares? Like why do you care if we can get more throughput, right? That's just a number. What does the number mean? Well, that number translates into saving money on purchasing literal capacity of machines across the planet. And it's not like, oh, you save you don't have to buy four more computers. Like, we're talking about like lots and lots and lots of money being saved for the business. So, like, is that the only way? Is it the only way that they ever could have achieved that solution to go save money? I would argue probably not, right? Is it the only way? No. But they came up with a proposal for a rewrite. And by the way, this is before I joined the team, right?

So like even I can see this in their messaging because it's so um it's so strong like the the reasons for doing it. There are so many beneficial reasons for doing it that it does make sense that they went and did a rewrite and they had a strategy for having like dual mode so that it's not like you know we we never touch the other thing and then like we swap it off like one day. So like we have to go away for a couple of years and hope that this thing works like no there was an incremental sort of rollout strategy a transition plan like all these things that make it a very like um solid argument for going in this direction. You can convince a bunch of different stakeholders that might go some of them would be like uh not only do I not really see a lot of value in that but I see a ton of risk.

Okay, for that stakeholder or that group of stakeholders, how do you demonstrate to them that you can minimize the risk? How do you get them to neutral on that? Right? You might have people that are like, "This does sound awesome, but I see a lot of risk." Again, how do you get them uh brought up from neutral to more positive? the people that are, you know, uh, really gung-ho about it and don't see a lot of risk, how can you act, how can you like make the value prop even more clear? You probably don't have to spend as much time with that target audience because they're already getting it. But like point is that you have different stakeholders that will care about different things and in some cases what they care about is just like you are adding risk. So this is just you know one super high level example where like the from where I'm working the the message is very very clear.

Now when someone comes to us or I hear conversations about people saying like let's just go rewrite it in a different language first thing that goes off for me is like alarm bells because I'm like a re like when I hear rewrite that's why rewrite is an extreme investment. A rewrite in a different language is even more extreme if you don't have the expertise in the language in house. I know this from experience seeing it. It's not that it's impossible. It's very much possible. But you must accept that you will have a velocity in terms of development that's going to be significantly slower. And if you're willing to like again if you can accept that and the tradeoff is still there then like okay then you make a business decision regarding this. Is it worth you know having significantly slower development because we don't have the expertise because what we're anticipating is this kind of tradeoff.

Now, if you were to start a conversation like that, it might like for me at least, I have a lot of um hesitation around that, right? So, unfortunately, I end up being the person who's like, I don't know, like that's not very convincing for me. You want to rewrite it in X? You want to rewrite it in Y? Like, how many people on the team know X or Y? One. Two. Okay. So, you're telling me that a team of like x number of people, we have one person to start with that can be productive. Okay. So, already I'm not feeling great about that. It's not impossible to solve, but I'm not feeling great. So, I'm kind of more on the negative side. And for me, like I'm I'm my goal is not just to shut people down because I'm like, I don't like some other language.

It's not C. Um, my goal is to be like pragmatic about what we can deliver. So, what's next? Like, what's the benefit? Okay. Well, you know, we're we're hoping to see like I'm just making this up. We're hoping to see like a a 2x performance improvement. I'm like, okay, that's that's pretty substantial. But then I want to go ask the question like, could we not get the 2x performance improvement just by using the technology we have and focusing on performance, right? And the again the goal is not to be like your idea is terrible. My goal is to say like if if that's uh you know if this is the uh objective we're after does it does it not make more sense to just start on that objective right now without starting from scratch but I like to go through this conversation to hear about

where the you know where are these opportunities in your proposal that that are something that we can't get a different way and in some cases like if you pick a language rewrite uh just to give you an example like if we're in C andnet there's garbage collection cool um is there a reason like a strong reason why in whatever we're building where like garbage collection is actually a really big problem there is okay like that's you know one more reason where maybe that is a really good uh benefit for doing that is garbage collection currently an issue for us no okay like do we have to worry about that that is are we speculating that that's going to be a problem or like hey garbage collection has shown routinely to be a problem in this type of service? Okay, like maybe maybe that is a a good reason to start considering this.

But I like to like it's pros and cons analysis, right? And at the end of the day, if you're going through that and looking at the pros and looking at the cons and you're like, the the pros outweigh the cons, even if there's some cons like people not having language experience or it's going to take significant time or whatever, then it's like, okay, you still might want to do it if the pros outweigh the cons. And how do we start minimizing the risk? Right? So just to give you an example, oh rewriting this language is we're anticipating 2x performance improvement. Okay, what happens if it's not? What happens if it's the exact same performance? Then like you're missing out on a huge benefit, right? So how do we derisk that? Can we do a prototype of some small part of this that can show like at a smaller scale without waiting like for a year of development?

Can we get an example of illustrating this performance improvement? Give us more confidence. Can we come up with a flighting strategy or a way to roll this out where it's not like flip the switch and hope that everything just works after 2 years of, you know, zero development on the original thing and 100% effort on the new thing. Like that sounds like a shitty risky trade-off to me. How do we how do we do both in parallel? right? Like what does that look like? So my point here being like when you're getting aligned on pros and cons, you're talking about the different things that stakeholders care about. How do we also go through the list of risks? Like it's um you have all these benefits that you're trying to list out. Great. And those might be the reason to do it. But when you're looking at all the cons and the risks, how do we start minimizing those as much as possible?

And that might mean more work, right? To go prototype something to get some evidence. That's more work. But like is that worth it? Like in my depending on what it is like perhaps for something like a rewrite, I would say I want to see a prototype to get some evidence. Um there might be like changes where and just making this up off the top of my head, right? Like with the rewrite example, um you're using a a language and there's some type of I don't know like hardware changes where it's like literally our stack cannot work on that hardware. Like there we're changing hardware and like we we just don't have a choice. we have to go to to some other uh technology stack. That's it. Okay. Like come up with a proposal for a different language. But it's not like sort of the argument goes out the window where it's like well what if we just take what we already have.

It's like you know you can't. So again um these things can change in your proposals. But uh overall I I really think that when people are struggling with this, they're unfortunately like kind of failing to realize that what they care about or what they think is valuable may not be aligned with what the business does and or they might be doing a poor job at communicating that. You know, I have a an example on the previous team I was on. Uh I don't you know, I'll share this because I feel like um apparently the camera battery only lasts for like 15 minutes. Stupid camera. Um yeah, I was just going to say I have an example from the previous team I was on. um where one of the projects that I had before we had a bit of a reorg was um my team had this challenge where in terms of optimizations like other other teams would be responsible for owning those optimizations.

Kind of tricky to explain but we had a framework other people plugged into it. um you know we would be the ones who can see the performance or the success rates of things and if one team decided to go add something in there that would screw it all up like it would look bad on us. So we are responsible for the overall health of it but that means that we have to go uh properly attribute to uh the teams that can impact it. So I had created a uh a system for this uh that we started to implement and uh when we had this sort of organizational change and we were doing planning I had said hey we like you know we have this thing we should continue it um and basically I got I got laughed at like legitimately I got laughed at in the meeting.

I'm not even when I say laughed at I mean not someone shrugged it off. I was on a call and someone laughed at me for it and um you know obviously that's shitty. Uh I would never never recommend that you do that to anyone. But um the sort of the lesson I learned from that was like the as part of that reorg the people that were were new to the group. They didn't understand the value proposition of that and I had failed at communicating that properly. Right? I don't think that deserves being laughed at. Um, but they didn't see the value and like I need to take some responsibility not for receiving a laugh but uh I have to take some responsibility in being like if they didn't get that who who was the one communicating it like that was me I failed to do that.

So the value prop is really around how much time the team spends for one of their core uh responsibilities. And so if this is if we agree that this is a core responsibility of the team is to maintain this because without it we lose the agility and that's actually the the entire charter of the team. Uh if we lose our agility we have a problem but in order to maintain it it's taking up the majority of the team's time. They can't do other things. This system frees up the time so that the team does not have to spend it manually. Right? So the the proposal is like we are spending so much development time and if we build this system we have more development time to go do the other enhancements or other feature work or anything else. Without it we have no capacity left. who are basically at at full capacity just trying to support this and history has proven that it's very easy to regress.

Um especially over time it can creep up. So the longer something waits the harder it is to go chase down. If we can catch it right away then great. So anyway that's what this idea was about. um after I left the team, uh I don't know how much longer it took, but they rep prioritized the work and I'm assuming it's because the team was operating and they ended up getting to the point where they're like, "Wow, there's a lot of time being spent on this." It's like, "Yeah, yeah, it's not good." So anyway, uh just a lesson in like I went through an experience like that where I did not communicate things effectively. That's on me. Don't laugh at people though. That's not nice. I will see you folks in the next video.