How Do Developers Deprecate Products and Services?

Transcript is auto-generated and may contain errors.

Hey folks, I am just leaving the office. It's way too late. Um, not how I planned for today to go, but that's okay. Some days are like that. Um, we're going to go to the Experience Dev subreddit. Um, I do have a pending question, but I tried so many times today to get videos filmed. Well, three times. That's uh that's enough. Um, so this is the fourth time I had microphone issues. I couldn't find my mic cuz I didn't have it in the car. uh all sorts of stuff, but we're doing it. So, I wanted to do this talk from a topic on the experience dev subreddit where someone was asking about deprecating services and and what that looks like and to be maybe a little more generic like products and services kind of asking other experienced developers like what's your experience been like where you plan to do a V2, right?

There was a new version. What the heck happens? How do you get from version one to version two? What does that look like? And so I think there's a bunch of different ways to look at this and I figured it'd be fun to talk about um because there are different angles to look at. So I think this person the way they talked about it was a little bit more from the perspective of like what like have you had this experience where customers weren't adopting a like a V2? And I thought that was kind of interesting because like um like I would almost expect and I guess I guess it depends on what you're building but could you imagine as a consumer right um especially for software so you you're using a version of something right you got version got version one and it's awesome and you love it and company's like hey we got a version two and it's even better or that's what they're saying, right?

Like for me, I would be like, "Hey, like, yeah, give me version two." Like, I'm not if I don't have to pay for it cuz it's the same product. I've already bought it and I can upgrade to version two. Like, hell yeah. Like, give me give me the new hotness. Right. It would be pretty rare, at least from from my perspective as a consumer, that I would be like, "No, I don't want that." Now, can I think of some examples where that might cause some friction? Sure. Like, so one would be, hey, look, you're on version one and you've paid for it, but version two, that's where we're putting all of our effort and it's going to cost you, right? Like a common thing like this is video games, right?

Like you play a video game, you play, you know, version one of it, you sync tons of hours into it, and then your your favorite game publisher is like, "Hey, we got a version two, right?" And so, hey, if you really like the game, the publisher, then odds are, yeah, you'll probably pony up some money for for version two. But like, some people might not. It might depend on that relationship with the publisher, what the game's like, their, you know, the game philosophy around, you know, are they just releasing another version to get more money out of us? Um, there's some games I can think of like uh like Path of Exile is a game right now, right, where there's a Path of Exile 2 and there's still tons of people that play Path of Exile 1, right? Um, there's, you know, we take another video game like Diablo, right?

There's lots of people who play uh Diablo 2. Well, they have Diablo II resurrected now. Um, there's Diablo II, there's Diablo 4. They got players across these different versions. And so maybe they're like, I don't want a pony at more money. I got the thing I want. So you got people stuck on the old stuff. Um, another reason why people might not want to upgrade is um could be like data compatibility, right? So if say if you're a a business and uh so you're using version one of the software and it has files and stuff that are saved in a certain format, you use those things in other systems. You have like sort of your business processes built around this. And then a company's like, "Well, we got version two and it's going to be the new hotness. By the way, version two has a new cool file format." And you're like, "Whoa, whoa, whoa, hold on.

What do you mean new file format? Like we've, you know, our business is built around file format looking like ABC. What do you mean the file format's going to look like XYZ now?" Right? Like that's not okay. We can't upgrade to that. Right? We have a data compatibility issue. Um, you might imagine too like I'm talking about like software products. What about uh things that are like APIs, right? What if your product the way that people integrate or use that product, it is an API. You have a service with an API. People pay to use that. You could be in situations where I mean this is very much like a a software focused thing. You have people stuck on the old API cuz they're not ready to upgrade, right? So there's lots of people that you know for for their line of work, they're building APIs for products and services and the customers or other developers using that and integrating.

So you might imagine those types of people kind of run into this kind of all the time where they got tons of customers on some version and you're like you might be in situations where as the developer you're like we have to you know we have to cut off the life support here for this thing. Uh you know we're trying to get to version 20 and people are still stuck on version 11. Like no like it's end of life. We got to kill this thing. Um, so I think there's lots of stuff like this that could happen. I was also thinking about this from the perspective um I'm jumping around a little bit but this person like I said was kind of talking about like consumers but I was like what about situations where like you're doing a rewrite and like you don't even have people that are directly buying your software like you are you know for example uh I work on a platform team right like people aren't like buying our platform platform.

We have partner services that onboard to our platform. We route traffic for them. But like if we wanted to do a rewrite like that's on us to like you know adopt the next version and stuff. It's not a partner that's like hey we're not you know we're not doing it. No like that's us to go roll things out. So you have this situation where um you know depending on on what you're building it's like you have version one that's deployed in places you got to get version two deployed. Is it just a uh sorry when I'm saying version two I don't just mean like you've uh you know changed a couple files and like you're going to make a bug fix. I mean like you've you've made a second whole version of the thing like a rewrite. So how do you get this thing out there?

Right? can't well I'm not saying you can't shouldn't say that but it's really difficult to snap your fingers and have everything just cut over to you know to new hotness version two. Um odds are you need to have some period where like you're say if it's an actual service it's running like moving some traffic over to it and then like as that traffic's moving over you have to like take out the old versions. um depending on the scale that you're at. It might take you a long time to do that. uh not only to roll it out. Imagine cuz I'm not sure how many people have had to do this in their careers so far, but um if you've done rewrites before, I've talked about rewrites and refactoring on this channel a bunch, but when you have to rewrite, a lot of people uh and when I say a lot, I mean essentially everyone um underestimates how much has accumulated and what it means to get to feature parody, right?

So, if you were like, "Hey, we want to do a rewrite and that's going to be the new hotness." If you were to sit there and say, "Cool, we're just going to build until we've reached feature parody, but in in the new hotness," you might be sitting there for like years trying to get to feature parody because you're constantly discovering, "Oh yeah, we actually do have this feature, right?" There's so much depending on uh you know the maturity of your software. There's so much stuff that gets built in and just trying to reach feature parody alone could take a long time. So a lot of the time how this will work is that you'll you might have a like an MVP or a thin slice of what's actually been, you know, written in the new hotness. I keep saying that. It's fun to say. Um, this person's going way below the speed limit.

And so you get that running and then you start like introducing the the the other things over time to kind of catch up. Um, you could even do this when you're thinking about rewrites of parts of a system over time. And there's a like a term that's coined for this called like the strangler fig approach where you end up like you do a rewrite of a piece and then you like slowly like move traffic or like calls over to this thing and then you do that for the next part and you slowly like strangle out sort of the older legacy parts of the system. So all of this just to say so far like I think this is an interesting challenge to think about because it could be from the direction of like customers adopting things and like do you have some resistance there rightfully

so right is it opinion based is it because like there's actually people's businesses depend on certain versions of things all sorts of reasons and then I think there's this also this like approach where you think about it from the develop er perspective, the people building the thing. Someone else going below the speed limit. One sec. I sat in traffic for like an hour and a half this morning and so like I'm not screwing around sitting behind people going below the speed limit uh when I'm driving home from work at 7:00 at night. Um, so yeah, that and this other perspective of like as a development team, how do you like get things over to the next version? You might find yourself like we're stuck in this in between state for forever for years, right? I think um there was this cool experience like I want to talk a little bit more about like actual um real lived experiences for me on the current team that I'm on.

You know, when I joined the team, they were in the process of of doing like a migration for a live service. And like for for context, the scale of what we do is I I've said this on the channel before, like we route trillions of requests per day. And so you can imagine a system like that is not something where you like snap your fingers and it's just done. So, not only does it take a long time to actually get rolled out and have it getting used properly, but also like again to build feature parody that's also going to take time. So, uh, for me it was really cool cuz I got to join this team. Uh, while they had, I would say like they got past one of the big hurdles in the beginning, which is like how do we kind of use these systems in tandem and then it was a matter of like cool over time how do you shift traffic?

How do you kind of it's almost like using the strangler fig approach where you can say over time we have more and more support. um until the old one is just no longer serving a purpose at all and you can finally get rid of it. So, I got to live through that on this team, which is really cool. But, of course, like I was saying, there's um you know, you might have this big um hurdle in the beginning, which is like how do we get it started and get to a point where there's some usability that warrants us using it and it's practical or it's more efficient, like it's having value. How do you get to that part is a huge hurdle and then I would say there's probably like a period in the middle that is hopefully like smooth more smooth sailing because you're

like okay we see the pattern to do the migration got to get some momentum and then I think there's this like the tail end of it is also another hurdle which is like you got all you know the majority scenario kind of done now you got the tail end that's like these outliers or there's some weird going on that uh maybe you have other teams that have to do something like basically it's the outlier stuff and it's the stuff that's at the end keeping you from finishing all of the work. So, um, was, like I said, it was really cool to be able to see that kind of come together. And it it really did pan out that way where the tail end has like the special snowflakes, the things that are a little bit more complicated than the rest and and couldn't be addressed the same way.

So, um, multi-year project, right? Like huge huge migration, but business decision to do it. Um, lots of investment to go do it. And it's because like that investment made a lot of sense for the business to be able to to move in that direction. So, um you know, it's one of those things where I mean some people get into these situations where they're doing rewrites and they get partway in and they're like, "Oh god, like what what have we gotten ourselves into?" Right? like this seemed like such a good idea but now like you know sunk calls fallacy that kind of stuff will will uh creep up on you but you know this is a good example of like this was the right thing to go do you know are there hurdles and unexpected things along the way of course it's like any big software

project but um yeah I think it was a really cool one uh earlier in my career we had uh you know completely different kind of setup because what I was just talking about was from like a platform perspective and like so we're some infrastructure we're a platform and earlier in my career we had an example where we had a product rewrite and so this came with like um you know pricing changes so like how are users going to react to that? Is there like a grandfathering system where like hey you bought at this price and you've been a customer so like hey you get the next version of this because you know like we're we're putting all of our effort into the new generation of the software. Do we have to maintain multiple versions? Like do we keep the legacy one? What happens how what does that mean for a development team where you're like hey go build the new hotness.

All of the development resources go into that. Oh, and by the way, like that other thing that we're not going to be building any more into. Yeah, you also still have to do bug fixes and support it in. And then maybe periodically there is a feature we're going to ask you to put back into that. Like that's a that's not a great situation to be in, but a very real one. So we had, you know, pricing changes, uh, licensing changes around like grandfathering or not. We had data format changes. Um, we had we had this huge thing around feature parody. Like this is I had to learn this the hard way, right? This was my first really big rewrite.

And you know I think for us that's what like one of my biggest takeaways from that entire experience was like uh I'll come back to like the maybe more of the business side and making decisions around that and the product but like as a as a software engineer thinking about how much of a headache it was to to be realizing like just how many features were in the original product and when we're talking about building the new one, it's almost like it's so easy to say, "Oh, just make it look like X and like we'll just have a how, you know, here's the features we use." And you start building it and you're like, "Wait a second, like what about feature A? Like no one no one talked about that, but that's in the original one. What about feature B?" And oh we forgot that, too.

And what ends up happening is like there's this inventory of features and functionality that that seem like they're I don't know like people forgot about them and you kind of find them along the way and it really makes you realize like I said just how much you know functionality was sort of in the first version. One of the frustrating well lots of frustrating things about that but one of the frustrating things is when you're when you're doing something like this a lot of people are like great we can focus on like finally architecting this software the right way right well we'll make you know not good the first time of course we'll make it perfect the second time. Haha. Um yeah and because you can't you don't even know all the features you have and that you need. What makes you think that you're gonna build it perfect the second time if you don't even know what features you have to build for because you don't even have an inventory of all the features, right?

It's uh it's kind of crazy. And I should mention too, it's not when you're doing this kind of thing, maybe there's features that you don't want to port forward. That's a conscious decision, right? So that was a really difficult thing to go through as a developer because there was constantly like I don't even know how to say this properly. It's almost like you you had to pivot a lot still, but like why are we pivoting so much when it's like a it's a product we already know? Like we already know that we're doing the the new version of this. It's the thing we know. We're just making it better. But like we're still pivoting because we're realizing, oh we forgot about these features or and sorry, we forgot about these features and we have to go build them or we forgot about these features. We have to have a a hard conversation about whether or not we need them or not.

Like do they really fit into this paradigm anymore? So that was that was pretty crappy. Um, but you know to kind of look at this thing overall, we we were in a situation where we were doing a a rewrite of a new product while still maintaining and not dropping the ball on the previous product. So that was a lot of time and energy like just overhead for doing kind of these things in parallel. Um, and yeah, like like I was saying uh for the other example, sort of this we still have this scenario of like this last mile of like, you know, somewhere in the middle we're really hitting our stride with momentum and it's like okay to get this thing over the finish line where we want to ship it.

Like that's where we're again starting to uncover some of these gaps and like you know how how crappy is that going to be to be like cool here's the new thing here's the why the price is increasing or why we have to have new licensing models like here's all of this stuff that we've like all these features and things that we've built put all this time and energy into just for someone to be like oh but like what about this like it doesn't even do that thing that the old one does right like what makes you think I'm going to buy the new one if it doesn't even do the same thing that I use in the old one.

So really challenging but um I think from a like to come back to like the business and product perspective like I wasn't making decisions on those things and I I'm happy because like like that was those are really difficult decisions to be able to say look like we're not only are we building like um sort of the what we would call like the next generation of the the software ware, but like we're also transitioning that from like it's a much more purpose-built tool to being something that's a lot more like a platform. And so like I got to pass this guy one second. Um, like it it literally does justify a a price increase because if you're trying to revamp things so that you have a platform to be offering, you know, this next generation of functionality and features, that is a lot of time, effort, engineering resources like to be able to offer something of significantly more value.

So to me like it's I kind of see both sides where it's like yeah you as a business you're like we want to make this bigger better thing and it's because it is bigger and better it should be valued higher. That makes sense and like it's going to take time and energy and resources. So again that's why it should be valued higher. And then also, if you're thinking about it from the customer side, some customers can absolutely rationalize that. They're like, "Yeah, if you're going to build something that is going to be way bigger, better, more awesome, then yeah, like, you know, if that's a product we we need and we want to continue with that, then yeah, the price is justified. But then you'll also have customers that are like, I just don't care for all of that other stuff. Like, this was good." like if you would have kept on with your normal updates and stuff like I would have been happy with this.

I don't want this other bigger, you know, apparently better thing that you're uh offering. Like you're kind of screwing me over. So, I think those conversations were super interesting to at least like observe and hear about. Uh, but like I said, I'm I'm glad I didn't have to like make the executive decision on how all that works cuz certainly I I would not know how to navigate that. Would I today? I don't know. Like probably better than I could have whatever like 10 years ago. But I don't I don't think it's easy, right? I think that's a that's a really difficult thing to have to figure out. But yeah, I think, you know, I wanted to share some of that because I' I've kind of done it from those two angles that I was talking about where you have like how how are your customers going to react to this kind of thing, right?

Um, and then also from the perspective of not even customers, but like you're a development team. What are you going to do about having, you know, something rewritten? How are you going to get that to the finish line. Um, yeah. And honestly, the the the folks that I've talked to that have done rewrites, it's not um it's not that a rewrite's never warranted. Uh, I think there's lots of reasons why uh, and whether or not you call it a rewrite versus like we're just making like the next thing. Um, you know, label it what you want, but I, like I said, I think a lot of people really really underestimate how much time and effort goes into that. And I kind of wanted to wrap up this video with like this other thought which is like we're can't make a video without talking about AI, right?

So, um, with AI, we get a lot of people that are like, "Oh, I mean the code is the the cheap part now, right? Like we just have AI write the code." Oh, yeah. And you can that's great, right? Even if you assume it's perfect, right? Let's let's pretend together that you're going to have AI do this rewrite and it's going to do it perfectly for you. And let's again pretend that that is the case and that you could be confident that it's done perfectly. Okay, cool. So now you've snapped your fingers. AI did the thing. You have your perfect rewritten V2 awesomeness. It's written in Rust because, you know, Rust is the the best thing that's ever happened to uh the universe and you can't possibly have bugs in your Rust code. It's never it's never happened. And so now you have this and then what, right?

like you you you can use AI to speed these things up but that's not the whole battle which I think is something that is completely being missed in a lot of conversations these days um you know you have a service what like how are you going to go roll out this whole new thing switch traffic over move customers over um migrate data depending depending on what your service is, right? or it's a new it's a new app that you're launching and like how are you going to get everyone to download the new app or what like whatever it is when you have just because you have the software the code actually rewritten in the new the new version just and you had AI do it all for you and it was perfect like yeah those are hard things to figure out but it's still not the whole Hey, there's a lot of crazy driving going on right now.

There's like two people on motorized scooters that were and I don't mean like sit down motorized scooters. I mean like two wheel standup scooters get in the way. This guy doesn't have his lights on like an idiot. Oh my goodness, buddy. It's pitch blackout. How are you even driving a vehicle? How does that happen? How do you get in your car, you start driving, and you're like, "Wow, I can't see shit." I'll keep going. I don't know. Anyway, it's been a long day. Um, I don't know. Hope that was kind of interesting to talk through. And yeah, if you've if you've been through rewrites, you know, new new products that are like superseding old ones, would love to hear your experience what that's been like. you know, was it more did it go smoothly? Uh what made it go smoothly? Was it something that was more customerf facing and everyone was, you know, quick to eat it up?

Were people pissed off and were like, "Screw that. We're not getting the new one." What did that look like? I think it's uh you know, not a not a rare thing that happens for for products and services, but I think it's a a challenging one. So, like I said, hopefully that's helpful. So, if you got questions about software engineering or career development, leave them below in the comments. Otherwise, you can go to codemute.com, submit stuff anonymously that way, and I will make a video response. And I do have a couple pending right now that making some follow-up videos now that my shit's working again. So, I will see you in the next one. Take care.