Arguing Agile

AA245 - Legacy Code: Why Big Rewrites Fail (And What Actually Works)

• Brian Orlando • Season 1 • Episode 245

Share episode

Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.

0:00 | 1:03:34

Legacy systems work. So why do companies waste millions rewriting them? 

In this episode of Arguing Agile, Product Manager Nisha Patel joins Product Manager Brian Orlando and Enterprise Business Agility Consultant Om Patel for a debate on the dangerous obsession with rewriting legacy systems — from COBOL to green screens — that still power ATMs, government systems, and Fortune 500 billing engines. 

Watch or listen as we discuss the myth that "modern" equals "better" and reveal how most rewrites fail because they ignore customer value, edge cases, and real ROI as well as other topics, such as:

  • How Chesterton’s Fence applies to code (Brian still doesn't know)
  • How Developers kill software with Resume-Driven Development (RDD)
  • How Finance kills software with spreadsheet-driven development (SDD)
  • Why chasing "parity" kills innovation
  • Risk Mitigation, or, framing technical debt in business terms

If you've ever worked on or tried to replace legacy systems, this episode will either give you nightmares, or help how you approach legacy systems while helping you also stop burning budget on vanity projects.

#LegacyCode #ProductManagement #AgileCoaching

REFERENCES
AA148 - An Introduction to Software Development Finances

LINKS
YouTube: https://www.youtube.com/@arguingagile
Spotify: https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3
Apple: https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596

INTRO MUSIC
Toronto Is My Beat
By Whitewolf (Source: https://ccmixter.org/files/whitewolf225/60181)
CC BY 4.0 DEED (https://creativecommons.org/licenses/by/4.0/deed.en)

Okay, Nisha. Here we go. I'm gonna say it like refactoring It's a hobby like if the customer can't tell the difference Why why would you change the system at all like about the product manager and the customer can't tell the difference? I'm not paying for changes It's called risk mitigation not refactoring like let's let's talk my language It's risk and money not just clean code and develop our happiness Objection All right, we need to get into this about legacy systems Stripping buckle up. Let's go. welcome back to arguing agile. This is your first time. Welcome. I am product manager Brian Orlando This is product manager knee ship atel. Wait, where is where's home? Oh there he is enterprise business agility coach Mr Oh, Patel and the salt and the swing. It's he's back to being the salt and the swing on this podcast because listen We're talking about legacy code today, and there's no new ideas here. should you rewrite it should you refactor it? Should you call it risk mitigation and get on with your life? That's what we're talking about today plenty of companies We'll go through modernization with their systems and I've been it I've been at a couple companies that have done this with their ERP systems They turn over their ERP systems every Three years, right or maybe five at the most extreme, but on a regular basis And and then the government of course is the absolute worst for this worst best maybe and also FinTech Has a bunch of systems running on cobalt like in production two -day That worked just fine So this is a legacy systems should we refactor them? Should we pull them out redesign them? top the bottom That's a podcast today So by the end of this podcast you will be able to spot Resume driven development. That's that's my term for you can already tell I'm given away what side I'm going to be on the podcast right now resume RDD resume driven development before it starts burning your budget away You're gonna understand why big rewrites fail in actuality right and then we're gonna talk about what works instead We're gonna talk about some stories about what works instead and then you'll be able to hopefully frame The technical debt in language that your business slash leadership approves of So oh Here's a question Nobody asks nobody why are we so show obsessed with replacing code that actually works Yes, I said code I meant cobalt Sorry, not true. Legacy systems in production especially like in government for example and also like every ATM in the world, they're all running on cobalt nobody understands all the systems They haven't a work What are we all worried about? so folks listening out there and watching please don't be under the misapprehension mis impression whatever Misunderstanding that this is about cobalt. It's not this is about running Legacy systems that run just fine right? And so some examples, right? There's a lot of assembler stuff out there still And it works just great so should we mess with what works or should we just leave it alone There's a couple of schools of thought here. One is the old stuff even though it stands upright works great It's missing features and functionality that we need today So the the Chesterton's offense principle which I had never heard of until we were planning for this podcast Chesterton fence a Chesterton yes, Chesterton. I didn't know who Chesterton is. I don't I didn't go in his yard He says don't don't remove something until you understand why it was put there the point you're bringing out There are two steel man points and I think it's an appropriate time to bring up the two steel man points Which is number one The cognitive load of changing these legacy systems. It's just too high and then along with another like a sub bullet of the price being high is We can't hire people because it costs too much or the true rare to find It's a little bit just ingenuous in this economy because like you probably could find those people but It may be maybe not but like those are the two points that people are gonna use is like well This talent is aging out or whatever and it's hard to find people They really know what they're doing and everyone's retiring and also even if it didn't it would take a long time to make these legacy changes to cobo I think people that told that line will say instead of doing the factoring Why don't we use expertise that's available to us to build a replacement system right with All the flaws gone and all the new features that we need added in there, right? Okay, reasonable line of thinking, but it's not like that's a cheaper alternative Right, that's the first thing Okay, you know these days people said but we can wipe code that stuff It'll help but it's not going to replace the core domain knowledge you need that becomes a skeleton of the system There are a lot of people out there still working on to your point earlier about you know, cobo systems They work these people have the expertise. They're still around But what I'm seeing nowadays is there's not that many of them like this fear of them right and they're commanding a premium So what do you do do you pay them that and just make sure that they can keep Slapping mandates on it and you know make sure it doesn't fall fall down or do you just say hey? Let's get into a lab. Let's get your brain tapped and we can create a new replacement system So those are the two still men here You know, I know which side I'm gonna be on so I don't want to give away my my cards just yet what do you think these you what what what side do you on here Is the rush to build something else do you think it's because oh these systems are just too expensive or is there like a fear of something else happening You know, I mean I think that it's it's easy to sell this bright shiny new Let's build it from scratch and it's I have a car that's paid off. It's running well But what if I can get that newer model that that's what I'm selling to my stakeholder right like If we can do this then you get the brightest shinyest newest model But on the other hand what what comes with this bright shiny new model like is it going to have additional features that actually matter Or am I gonna just as soon as I get in the car am I gonna turn all those features off and What Doesn't matter you're kind of you're kind of selling FOMO at that point You are absolutely selling FOMO as opposed to either of these points in this category I think about every large complex Database at the core of the system that ever worked on were like it started as six tables and then four years later It's 600 tables and no one developer even though they will claim they know what it does No one developer knows well. Yeah, right That's kind of this is like the opposite case of this or the a alternate case of this. That's interesting You know, but the I think The point here that I don't think any of us has yet to push against is That code has survived in production and worked So when you go to rebuild the system because of whatever like what your management is convinced about whatever reason Like the ship has sailed The first thing you're going to want to do as a product manager in that in that Case is gonna be what like I would expect the first thing you want to do is like take the core pieces of system that making people most happy And just replicate those as is and try not to you know The ship's got a sail and not take on water. Okay, like let me do that bare bones minimum and then get on other things Yeah, I think someone that depends on two things one is the appetite that you have to revolutionize your product And then the other is You've had a money you have to do it with You mentioned car analogy and I think that holds true here You got these new features a lot of people either don't like don't trust or whatever Don't use them turn them off later, you know So that's true, but as a product manager you've done you do diligence, let's say And you said okay, this old system doesn't have some of these new things that are current customers may pay for and definitely new prospects are looking for So if that's the case Your decision is easier to make right then you're going to create a new product And he'll take the skeleton of the old one for the new one and then stress test the market that way there is another angle to this which is What happens in the case when your finance people come and say this system That was developed decades ago It's seen better days. We need to get rid of that. We need to build a new system out that we can Account wise account accounting wise. Sorry Emeritize over the next three years to five. Oh, no, so like I want to stop you right there because we're gonna get to The private equity session The private equity portion of this podcast later, so I want to save that one for later because the the the specific case of the Like the finance people running our organization like a spreadsheet rather than an organization that like makes customers happy That's a separate case. We're gonna put that in his own special category Then we're gonna pat it on the head and send it out to its special place. Yeah We're gonna set it to a farm -up state is what I'm saying exactly. it's it's private equity for sure But it's also the government, right? It's you know, it's not just private equity But yeah, we'll talk more about that new course is there a time when other of you have seen a team Rip out legacy code only to discover that the new code they put in a replace didn't handle all the messy Quote edge cases that said edge cases in a quote because sometimes what developers consider edge cases and the product people consider edge cases The customers are like yeah, we use that all the time Because I will tell you right now like we we did this We did this at a logistics firm that I was at we replaced an old legacy Well tried to replace an old legacy billing system with great planes We did we didn't export to try to export not not do the fee. Anyway, it was a disaster because the old legacy billing system It had so many I mean the Kate the code basically was all edge cases And everybody hated it because they hated a bunch of if else whatever I got. I don't know what I don't know what Oh jeez. What was it? I think it was job on the 400 I don't remember I don't remember what the coding language was but Whatever the whatever the coding language was on the AS 400 it basically was all a bunch of if else statements Like forever or LLL if I don't know what they do in the fence. Yeah, I don't know yeah, I don't know what they do in a bunch of cases Yeah, but a case maybe cases. I don't remember what it was But all the developers universally in the firm I remember who were all a bunch of C sharp developers could not stand even like being in the same room With that code on the screen because they couldn't couldn't deal with it They're like this is the worst code in the world But it obviously like it ran the system fine. So it was just you know going back to risk mitigation like that what what's the cost of Putting that new That brand new shiny code into place when all reliable works just fine It's I mean that that was that was the problem. the way that story ends that that firm never moved over off of that code The whole time I was there every time I would try to move off that code They would basically abandon that effort and say like this is not worth it. It's not worth the money And they would just they would just go get the one developer out of cold storage Sorry, I don't know I don't worry. He sat and they would and they would put him in go get in there kid Go put an enhancement and he would do an enhancement and run through qa and You know all the old the old project management way of doing enhancements and it would be fine And then nobody was happy, but the customers were that's the key of this podcast is like Nobody internally was happy, but the customers were happy I'm gonna tee off of that and my example's a little bit Different in that this isn't about ripping out legacy code and placing it with brand new code that you've just developed But the central tenet this is still the same and so Who really needs it and who's going to care for it? Who's gonna pay for it, right? I was at a company where it was at the cusp of Windows everybody was creating Windows applications right to that it was green screen and we had a solid Very solid green screen application that had been running for a long while time and yeah We were maintaining it keeping it going adding functionality and everything But guess what the market is looking for Windows -based systems right so whenever our salespeople went out to conferences or prospecting That's the first question that was asked to sit around on windows And because we didn't have a product there. I don't mean those the answer was not yet. We can port it over right and we lose those sales so Coming back to the main point of this like who cares, right? It's the customers that cares, but what's the pain point? The pain point was with the green screen system They had to remember the tight commands And people would have a cheat sheet of commands based literally pasted the side of the dumb terminus So they would remember what you did right yeah that's the pain point or a pace it over the keyboard I remember that I remember that world. I remember that world. Yeah. Yeah, so it's to kind of mitigate the point here the pain points here I think no, I mean, I don't think you're mitigate. I think you're making one of the main points in this category, which is not in our notes which is if the world of UX surpasses Your legacy stuff. Yeah, and the expectations you users will basically lap you and that is that's a valid reason to do what What like the majority of this category kind of pushed back against my bother who works just leave it I'm yeah, leave it out there, but and I've been on the defending side for most of this podcast so far But that's the first like real valid like make me change my opinion thing is like well the world of UX is kind of lap This the world of UX is like if you're putting out there on the interwebs It needs to be like mobile phone accessible and your old green screen stuff is like nobody can get to that on their phone Any of they could you know how to help you head f12 on your phone I mean, so before jumping straight to a completely transformed new system that ran in native windows Company made a decision and that is the solve for the pain points not necessarily for the wishes and wants, right? So we changed our system and hit all the commands below Dropdowns and pop -ups, which is really all most windows systems have anyway. You have many systems, right And when you go down the list there's pop-ups next to it. You go to the file menu like save as open, etc we did that in green screen So that did two things one is cut into the pain point throw away those cheat sheets Yeah, and the keyboard overlays and in the other way is No development costs well not much development costs, right? And it made the transition to a true windows -based system You know valid meaning we knew that people were willing to pay the the deltas to go to a system that just you could install by using an MSI installer so that's an example of where You have the time this right and if you do that you're solving the right pain points Any investment you make getting out of that old You know tech that legacy whatever you want to say It's worth a while We managed to retain every single customer as a result of that Fast forwarding we lost a few because the next question they asked is does it run on a map? It doesn't run on a map. Oh, it does if you don't parallel on a map. You know, I'll go away Don't don't worry. You've hit on a good point of like You of understanding the customer's true Problem what problem is that you're trying to solve not coming with a solution But understanding the customers needs it's not that they necessarily needed windows application It's that they needed to run the program on a windows computer if I understood that correctly Yep, and not have to remember all those commands exactly and so In that situation the you don't need to build a full windows Accessible application. It was just implementing a solution that worked on a windows computer right incidentally what happened is our Competitors went the other way right so they went ahead and refactored their old legacy stuff into brand new Windows applications. Yep, and of course they had been points right there I mean you can't just lift the shift. It's a rewrite first of all and so in those rewrites They had bugs and they had issues and they had this satisfied customers and are You know our existing customers. There's no drama. Yeah, right which was great I wrote down three things For us in this category. I wrote down number one. Can anyone oh so before you embark on one of these great re -factor voyages The Chester Tins fence check. I'm still not sure what Chester Tins fence is But if there's a check we're gonna say Can anyone explain why this code exists or function or whatever you know, whatever you're looking at What edge cases does it handle which we talked about edge case today? And then has anyone traced all the downstream I'm gonna say dependencies. What I really mean is like second third x number order effects Is what I mean impact yeah impact And then like this is all like product management 101 before product management was a thing That's right before product management was a thing. I mean like in like 2014 is what I'm talking about this was this was the not some bolts of a Business analysis was these things tracing the downstream effects Okay, Anyway let us know in the comments If you found this discussion logical and useful and not on fire so we've established that legacy code deserves respect however That doesn't stop anyone from pushing for a full top the bottom rewrite speaking away some money. Oh, sorry. That's that's I don't mean to lead this conversation Speaking of ways of money. your lead engineer says you need to rewrite a platform to quote scale And I mean, do you really need to do that or they just trying to put a new framework on their link and profile That's my question to y 'all and That's that's a question of this one is is is a lot of refactoring this down with legacy systems. Is it just done True pad resumes although it's known as rdd resume driven development It's a thing apparently It's not but I mean I'm trying to make it one. That's what I'm saying. I think you'll find it is a thing talk to some of the Some of the architects the enterprise owners especially right Oh, sorry, I think we established in a previous book. I guess I don't talk to solutions architects For enterprise architecture. Whatever they're called today I mean like like I know I'm being sassy, but the two the two steel man points here are very clear Which is a modern problems require modern solutions. Sorry I know I was I was trying to say that seriously But it came across very day shapel. I was like a modern problems Like modern frameworks like you that there are modern frameworks and they're good So why wouldn't you use that like for a for example if you're doing pilot development like why are you not using fast API It's very good. Use it for everything. I use it for everything throw it in there And then the other one is like the the outdated sacks like it makes it very It is a rehash of our previous category But it is a good rehash here saying hey you've got this old legacy code and this old stack Why not rewrite it because that old stack makes it makes finding people to do things nearly impossible or maybe not nearly impossible But like slightly difficult as we know making things slightly difficult for the modern organization Basically is akin to like breaking it on Yeah, let's unpack that's a reality. That is the reality. Yeah, so modern frameworks. I mean There's gonna be new frameworks all the time. We know this. Yeah, of course. There's one thing we know every day It says develop a productivity But if you've got legacy code that's running honestly all you're doing is maintaining it your productivity should be pretty high at that point Because assuming you're only dealing with You know anything that is a real issue like there's something causing pain not just because you're you know You're rewriting it for the sake of rewriting it or you're getting 2% faster execution time on a store procedure So you rewrite it. That's not the reason to do it So if that's the case now what right It's just because it's a modern framework doesn't really merit spending money on rewriting In my opinion at least like where's the ROI on Right I would agree what is the ROI like why why is your tech lead asking for this understanding What their pain point is Is is this solution that you're proposing of This change is it is it self -serving or is there real impact to The business the customer oh, I got I got you in this one. I got you on this one I worked at a workplace where This one developer with this one piece of technology He was the only developer who could work on that piece of technology and it drove them insane that they could not just go into that system and Jam out some code and just you know send it out or whatever and they had to go to that guy And explain to him why they wanted to change And explain to him exactly like what the flow chart was then he would ask them a bunch of questions about well If you go through this Path then these other branches will be changed and you go through this path These other customers that do this specific thing and then some people have this checkbox checked But there's only one or two of them, but they may be affected so we have to test those and he would make them I mean he wouldn't make them but he would caution them to say hey have you thought about all the effects And that would drive the normal development team insane To have to slow down For the pace of it it's sort of like if you ever run In the when I was in the military and you would run information sometimes they would put the tallest people in the front and then us short people I'm average height. I'm like five nine. I'm average height for a person But in the US military I am super short Because most of the people were like six for or taller and they'd be in the front and you'd have to run at their pace but occasionally The people would reverse and the short people would be in the front and then everyone else had to run at my pace This is the sort of thing is like I can only imagine the six foot three people Must have been super frustrated with my little shorty short footsteps as they're running information behind me They must have been feeling like they're running on their little tippy toes And that must be the way these developers were feeling because they were working on their specialty And the other developer was working on their specialty and they had to run it somebody else's speed But I call that teamwork now that I'm in product management the director of development had no empathy For this other alternate technology So of course when it came back to the leisure team and financing the discussion and sea level discussion about finance and budgets and stuff like that They're like this guy just slows us down and this technology is old We should get on with it. Just let you know. They're still on technology today Sorry, that one I was specifically seen is all the developers hated And the company just can't separate themselves from it because it's too crucial to their business It's painful as that sounds Stop and then tear out the old stuff It's even more expensive and possibly more painful than do it on a gradual scale So you're you can't take out the production system. It's already there right starting with you know band -aids or the rubber bands Yes, it doesn't matter. It's working right so you can't take that out but you can try to create Pieces of that as a replacement system or change modules in that system itself a major surgery it takes Much much pain to get there that way right that bad But you mentioned earlier is it self-serving in in a few cases it might be maybe your architects Tech leads aboard with the old technology. They're not getting anywhere professionally. They're not letting anything new So of course, you know, they're out there in all the forums and oh, this is the new hard thing So that's what we should do. what I mean, what do you think need she does it? when we were talking for the prep for this podcast It's when you try to go from the old legacy system To the new system because of whatever decision that was made right like is there a time frame Like are you trying to do you break it up into small Segments and then try to like cut customers over one by one to the new system or is there like Big swaths of things that you're trying to do like how are you approaching that? I mean, doesn't it make sense to cut over piece by piece so that you get incremental value so Let's let's make a statement and say that this new system will allow for more efficient Task if you can get that incrementally if you can get more efficient More efficient more efficient now you're sliding all your coins from this this pile to this pile Doesn't that prove more valuable then wait stop well it let's cut over So in my in the story that I was talking about it was a transactional billing system So the system when when a customer would scan a document what they would do is a customer would scan a transaction A transaction would come into the system and then the company that that customer worked for would get Build for the transaction and this was the transaction processing and And billing systems so two things together like I think about it as like a database that store the transactions And then a system that build a customer for those transactions. So the billing system and a processing system and It did it did make sense to cut over the systems in order to modernize them one at a time However Since the two real -time systems work together that would not be possible Like it I mean, I guess it could be possible and we did do some kind of some sort of like replication and stuff like that we did do some activities that tried to do that But again the whole time I worked there and then again years after I didn't work there From what I understand they never moved off of that system They did try several times to be like well Maybe we'll just take the transactions and put them over here and replicate them back into the old system And then the new system will work because the old system will just replicate it but the like replication had its flaws Yeah, you know like anything I tried to put it in place that was like a stopgap or whatever Had enough flaws where it just didn't work To and then they were stuck with the legacies. So it was like to me from my perspective as a product manager now many years later my career It's they just kept putting money in that slot machine and they never won and now you can say yeah, that's that's effort money Time that we could have been putting towards Innovation towards growing our customer base towards serving There's so many other things that you could have done You meaning that that company could have done for For actual growth versus this like short-sightedness Oh, this is legacy code Are you on the seal man side with me now because I think I think I think I brought you over to my side where this is This was just patting the director of developments resume at this point to say like oh, I am off of these legacy systems I save the company xyz money. I mean he wasn't thinking this way like this this ingenuous way I'm being super sassy for podcasts for But like the point you just made is a hundred percent valid if I was a CFO Or the CEO spending money with a concern CFO in a C -level executive meeting and it's like look the development team has spent a lot of money Trying to replace the system that works and like we don't need any changes I remember the the big thing with this system was we can do One -off manual corrections with our accounting staff And I remember asking like well how long does it take the accounting staff To update the manual changes. they do it on Monday Every whatever week or two weeks or maybe once a month. I don't know what it was It was like it wasn't it wasn't more than one day and it was like they maybe two hours Monthly or something like that with manual corrections They do the manual corrections in the in the legacy system The all the changes are up to get over to great planes and then they go out to the customers I'm what why are we spending all this money You know, why are we spending all this money? Oh because it because somebody somebody at some point Takes it as a point of pride that they got this Piece of technology. They're not accountable for That they are not responsible for But for some reason it's just this like blight on their career You know, let me ask you so who Who is your audience like if you're talking about wanting to update legacy code from Lord Voldemort he who shall not be named or is it coming from top down Like from a leadership level because the way that you're communicating to these two people Is going to be very different right like if you're Lord Voldemort like what What is it that's that's driving you what is your motivation is it resume driven development like are you trying to pad your resume maybe that's a that's a coaching Opportunity where you know if if you're looking to to grow maybe you can teach some of these developers what you know I'm passing on passing all this over to own because I know how this story ended in my in my career track I know how this story ended the story ended was anyone that ever tried to change that system That didn't have the customer in mind first Always failed Anyone who tried to change the system that was trying to do something benefit of the customer always got their change through To the legacy system and got to change through the process some somehow even though we don't have any people understand it Or we don't have any bays that understand the system or we don't have a full -end document Somehow the change always found a way to get done and process and successful and deploy the production Because you can communicate value when you're bringing impact to the customer and that's why that's why those initiatives succeed and the other ones Maybe not so much and The question of who will benefit from this change if it doesn't work out to be the end user of your software Like it's a disingenuous change and that's your trigger to push back against it or or do whatever right within your Responsibility Yeah, I mean look I've been on teams where the developers themselves know that they're working on legacy stuff Yeah, they don't like it right they want to be working on cutting edge sure So the other ones that will say if we can only Move this over to in certain new stack here because they're gonna work on it right and that Enthusiasm should not be curved necessarily, but you also can't just simply rely on that and say sure We'll just spend thousands on this right The other side of it is sometimes your customers will say We're old stuff and We have other vendors that are giving us this new stuff So it becomes more of a retention policy at that point Let those customers go or do you say here's what we'll do We'll give you a strategy that says over time Whatever right a year to will bring you over to the new stuff, but What works today will continue to work for you and you will not see any change or any pain at least As a result of that and that becomes one of those actionable strategies that you could implement as well The last thing I want to say here is if you're doing it because You've been kind of say you should and I know we have a spot for this later, but that's you know That's not gonna work out this Since you brought it up twice Since you brought it up twice we will definitely hold the spot in line for you right now So we're burning millions on so that we can make sure the development team doesn't get bored That's what I'm saying right now But if I'm gonna give you some signs that your your quote modernization project I'm gonna call it a project. I don't call things projects often on the podcast If I'm gonna give you some signs that your modernization project is actually RDD resume driven development. I'm gonna give you three things at number one the technology choice Mashes of what's hot on tech Twitter Not necessarily what's best for your customer number two your business case focuses on your developer experience We need to enhance the developer experience home. We need to bring on a product manager Specifically to enhance the developer experience across our entire stack Am I am I am I triggering you right now on the podcast because He's triggering me entire jobs right now like yeah, yeah And then and then the the loudest advocate is also the one most likely to leave in the next 18 months When they don't get their way they storm out Anyway, I like that that that meme that says I don't always code what I do It's in my driven I don't always go What I do whatever it is it's in cobalt. Yeah Oh boy. Oh boy. What do you think and what do you think about cobalt? So let us know in the comments here if you found this argument useful and And if if you're engaged in resume driven development and no one's gonna admit that they're Engaging And while you're there like and subscribe. Yeah, that's true. If we called out the selfish reasons for refactoring then Let's talk about legitimate cases because Rewrites fail even with good intentions even even if you're even if you're discapping all the bad experiences that Brian has had Which is all of them the big transformation Oh why it always fails. That's what we're gonna talk about So we name one big rewrite that shipped on time on budget and actually replace the old system and all the customers are happy Handle all the edge cases. Oh wait. Oh look. I'm dead. I waited all my let's say you wait a long time Yeah, right. like like things that you should never do. so the the big rewrite always fails as as a broad topic if if there's a pushback on this topic it says sometimes like technical debt Sometimes is genuinely insurmountable like the the the the whole this is not a political statement This is just the fact of like the the Elon Musk's crew went in like audit is security whatever like oh look at all these People that are you know, 3000 years old or whatever on social security is like they didn't understand how the Cobal code dealt with dates and stuff like that that kind of thing is like sometimes if you want like precision If you're like you're the product person you're like I need precision I didn't know exactly how old every single person is in this system And if you're saying like some dates can't be interpreted or some dates are not existing or whatever And then I can't have garbage data Then you need to enhance the software not to accept garbage data or to somehow have some kind of like Exception processing system built into the software which is completely possible To build this up in and and then the other one is like well incremental changes This is the other big one incremental changes cannot fix Large architectural flaws you can't increment your way out of like a deep dark hole You just need to like not be in that hole in the first place Like those are the two big ones here under the broad category of like well Here's why the like a big rewrite of legacy like is you need it like otherwise This is like that's in the fail so Insurmountable can mean a bunch of different things, right One is we don't have capacity so we're going to just keep building new features and will accumulate that over time I like we don't have capacity to me when I hear as a product person I hear I hear you have problems But we're not gonna give you any money so get back in there kid And and also What's the Amazon thing as like a shut up and keep quiet? No, sorry Something is on thing. It's a commit and disagreeing commit just disagreeing commit. Yeah, that's I was so close. I was so close I mean the tradeoff here is like you would hope That you can replace incrementally pieces of the system And cut over small pieces so like in in the in the in the example I used earlier where you had people Scanning things into the system small transactions coming into like credit card processing would be the same thing is like Okay, well at some point. I'm gonna cut over where like my API or whatever We're all the credit card transactions come in. I'm going to like Pull the DNS rug out from under the system and swap it over to the other system to where you know It takes all the same inputs and everything as the old system Except it does some new whatever thing right under hood And that's great if you can do that But then all the distribution of like the things that could happen with a transaction under hood Those now you fall into the trap of like we got to refract the whole system And test the whole system and now suddenly we've taken a big step back to the 80s now we're waterfall. Yeah Yeah, I mean part of the The argument with the insurmountable is also that right it's We're just in such a rush to get features implemented And we know we're taking shortcuts We'll come back to those later. Yeah, except later and never happens right so Deck that can be insurmountable in those kinds of cultures and it gets to the point where the house of cards is so wobbly That nobody wants to touch any card because it's gonna come crashing down advice. Oh run No, I mean like run. I was at a company one time where they they were cutting over from a previous mobile app to a new mobile app And the big thing of that company was feature parity they love same They would always misspell it parity they misspell parity They're like parity like like a weird al parity I mean like a party instead of like being instead of like one -to -one. Yeah, anyway, it was funny feature parity feature parity if it means that you pause business for a year Like by the time you launch it like parity Like you're gonna be dead like they don't have a company anymore at that point You're not you can't wait for this stuff It's gonna be a moving goalpost if you try to say I'll just like the credit card transactions will come in And I'll just slide the DNS out from a slide the DNS rug out from under and I'll put my new system in there Yeah, but where's it gonna go you're gonna help your wiring new system To all the old system at that point What are you doing in your life? So you're getting like it'll get deeper and deeper and deeper and deeper and you're gonna be like And then you'll end up being the guy saying we can't go live until everything is done up front Which is missing a thousand Congratulations, you're that guy You're gonna maintain two software systems one new one that everyone's gung -ho about and you know Tons of break fixes and tons of bugs And then the old stable system with its known issues That's the keyword known issues, right? So you already know what you know And that's the old system and and you've got people in place to deal with and issues that arise from there But the new one that's the unknown unknowns, right? So now you don't know how to stop your support people because you don't know What things are gonna come up and if you don't get it right people are gonna be disgruntled right is you're not providing good support It also gives you your developers and you support people like two systems to now look after instead of one So there's pros and cons and in this case mostly cons There's cons and cons Yeah, yeah, that's what I'm saying cons and cons speaking of cons we're gonna move on next category. If you have angry tweets to send that us about legacy system migrations that failed Let us know in the comments actually Don't let us know nishi do you want to know something that's gonna make you upset is that your finance team is Currently looking to undermine you as a product manager by saying hey, you know all those features and all that software sweet and everything you worked on Five years ago. it's completely worthless today and it needs to be completely replaced because we have a spreadsheet me said so and they're gonna lobby for that And they're gonna have the year of the cfo and the CEO and they're gonna win over you And that's the next category. I want to talk about okay That's about right Why I see I see I see by the way you said okay, You're not not not convinced I'm not all right. I need some convincing. I'm gonna so in my experience top software is typically depreciated between three and five years again My experience. It's all three years Recently, we started we started depreciating software at five years only because With AI's introduction to the market Everyone's kind of freaking out so they're going for longer They're going for longer depreciation terms, but like after after your full depreciation term The asset is worth zero and should be written off nothing not continually used for like five more years or whatever like this This is the same thing as like as soon as you're done paying off the car Right You're basically saying the car has no value at that point. boy? I wish Newton was here. It your car has no value at that point So there's a few things that don't back here, right? So the first thing is there is a IRS rule that says software assets must be depreciated between three to five years. Yes And if you go back on the history of that rule You'll find that the rules started at five years and it went to three years And now it's back to five years only because like you said, you know in the In the world of AI people are saying Just hedging our bit here. I just foresee if you fast forward another three to four years People will go back to less than three years and the reason is You can wipe code anything these days you know, you can just say well that code didn't cost us much to create in the first place So we could depreciate and write it off the books in a year if we had to So that's the first thing the second thing is does it have value after its amortization is over, right? This is for hard assets. We talk about that at cars. You know, your cars paid off. Okay, five years You paid off the five -year loan. That's it. It's your car now. Does it stop being valuable? Obviously not, right? It still has utility to you. Software does too to you But to your finance department Sorry, the answer is no. The answer is no. Yes. So for software and in the corporate world. Yes The car analogy doesn't fall into that category, right? So that's an individual decision. You say well You know, it's still works and I'm not ready to plug more money down on a new car Even though it has all these bells and whistles but and by the way every whatever two years three years when your company forces you to get a new laptop You're I don't want to get a new laptop I got like all my software is here and whatever and it's like it It's great and it performs and it does everything I need I don't want to get a big penny in a laptop and your company is like no you need to get a new one We're gonna ship you a new one. Yeah, this is why they they've they've determined the asset life of your laptop and said This brings us no business value After X number of years and and you may not be the owner of a you may have only had the laptop six months Because it's a hand me down because it's a hand me down But it's been used as the company continuously for two and a half years. It's got an asset life of three years Suddenly now you've got to pay the price we get one laptop You get all your stuff on it you get working whatever six months later You got to get a new one. They're all over again all right, so let's go back to the reason why why do companies do this? Right why amortize in the first place? it's really and I'm gonna say this without apologizing to the beancaps that might be listening here. It's really an accounting trick That's what it is what you're trying to do is to say every three years three five whatever What we need is we need an investment in in in the example of your laptop story there You know, it's in physical assets, right? We need to invest in physical assets. We don't do that. What happens? we don't get the money to invest in physical Assets that's one side of the coin, which means going forward You're not gonna get that budget if you ask for it because you haven't needed it the other side of the coin though, which I think is Maybe has some merit and that is that laptop becomes harder to support the older it gets right Same thing with the car analogy. So yeah five years is paid off, but does it break down more often? Increasingly in that world Cars don't break down. Nobody even freaking remembers what a car This So if it's a company car But if you had a company car like you would go the first like let's say you you wrote off your company car three years Like you drive a new car You company buys a brand new car Owns it three years. It never going to go as any major maintenance in three years Maybe you bring it back to the dealership every whatever six months or whatever you know three months whatever it is On a real basis And you're paying some kind of prepaid maintenance or whatever, but like you're not getting a new transmission in the first three years Of hopefully the first three years of car so you're basically just paying the cost Of paying for the car and that is you know, whatever minor oil changes stuff like that And that is it The variable costs of like well the CV axle went out on the rear differential one out or whatever went out You know the transmission need to be replaced those those weird Unpredictable this is about for finances about predictability that that's why at first nation You were like what the heck is this category about? I'm like Buckle up because this category is about putting my finances on rails And then driving them for a certain period of time 36 months whatever 16 months whatever it is And then making sure that everything is completely predictable for my c-suite so the numbers that are here each month are Completely predictable to the next month. That's what this is about So if the drive To replace your legacy systems that completely work the power all your ATMs have no problems at all It's because on the spreadsheet Can you tell me That exactly what it costs to maintain the software system all that cost if it's going to be exactly the same month over month for the next three years And you can bet your job on that then great it's not like a car. It's not like buying a building Software is not like that So if this if this category doesn't seem to work really well With this like old school finance way of thinking about it It's because it doesn't it's software doesn't work with this kind of model We've had a podcast on this with Newton. It is and it really doesn't work very well I think just for the Clarification of people that are listening Yes, of course companies that give you a company car aren't paying for the car upfront. Okay, they list these cars And that's fine. It actually works to your advantage if you're you know if you're the employee because Typically companies larger companies at least they don't just say hey here's the car that we decided you should be driving right They give you a Depending on your position in the company. They give you a range Of car prices that you can select the car from but they don't buy the car They actually lease the car obviously at advantageous rates You mentioned maintenance so a lot of times these leases come with maintenance thrown in at no cost of the company So a car dealership will say we will lease you 30 cars And you can bring it bring them all back to us for an oil change and a tire rotation will do it for free Because that's just jump change for them. So that's why they do that So that's the first thing is yeah, it doesn't mean you're incurring expenses upfront But now we come back to the real which is writing things off and amortizing it So what does amortization give you it doesn't give you anything on your current assets. Yeah, you're amortizing What it gives you is a clean slate for your next set of assets, right? You can't buy or lease New set of assets when you already invested in the old set of assets, right? So you have to get yourself out of that Right, so what you do is you just have typically it's a straight line amortization Typically software. I'll come back to that and say yeah, so for hardware hard assets cars whatever machinery It's a straight line depreciation over three years. It goes from X to you know Y to Z which is zero basically at that point or Z on the bike or Z Yeah, so that's how it works. It's it's three years Heinzwey dry Yeah, so that's it, but for software though here's the thing about software software is tricky To put a price on right, so what they do is they will simply say the price In round figures of software is Anything we spend to make that system Going to production. Did you have to lease servers? Did you have to buy servers? Did you have to buy or lease servers room space? Whatever all that goes in the same pack and then your developer costs your Three -year support cost maintenance cost that means you support people salaries and all of that that goes into it And now you come up with a number and that number is what they Amortize over three years when they're done. Guess what that gives them a clean slate again to come up with a new System should they want to so that's about amortization. That's why they do it Now coming back to how I feel about it. This is the personal part of the the podcast right I'm a bit ambivalent about it because look if you didn't do that you wouldn't have money available for new stuff So you just say right it's running fine keep it going You know just just I do support people or better yet offshore the support right Yeah, are you really working on the cutting edge? Are you interested in keeping your customers engaged? So they stay with you or are you gonna lose them to a competitor who's doing that So I'm kind of like on the fence about this. I think it's good and bad I just think that the whole accounting thing could be better explained to the layman that the people that I involved but yeah, that's how I feel about it And Newton if you're listening because you are let us know If we got this right or wrong or whatever Slesa in the comments below please What do you think about the statement that your finance book value has nothing to do with business value Be and I but before you answer like we did a podcast arguing I do one ninety three product life cycles Product like product life cycle phases from NDP to sunset a guide for product managers which probably in retrospect was that very like a mouthful words of a title But that the the whole point of that podcast by the way how long was that podcast is that 37 minutes. So the the point of that podcast was we talked about going through NDP Growth phase maturity phase and then sunset phase of your podcast 37 minutes. Because that's kind of what we're talking about here where like the the business value of the phase that you're in and what you're doing I'm like I think about I think about like what a lot of people here when they hear a legacy system is they hear a system in sunset is what they hear But like a legacy system could still be receiving enhancements could just be a mature system that doesn't go anywhere The reason I bring that up is because what you just brought up is like oh We're trying to book value off of this system and like write it down to zero and send it off into the sunset But customers is still asking for potentially paying for enhancements to the system And if you're in the spot where you're like you get the customers in the mode of paying for the upgrades I mean at that point like do you have a legacy system or you just have an active Like the last active cobalt in development system ever known to man or I think like what's underhood in this discussion is like people just not knowing what they have You know in there. It's like it's like the the capital one, but not a terrible company version of like what's in your wallet It's like what do you have in your portfolio? Do you know do you even know? Or you just want to like get out of this deal where you're like I got a cobalt system. I can't even spell cobalt. I don't want to deal with this And you're you know what? get me someone in the room who does want to deal with it I think I'm gonna make a good point about a definition of what is a legacy system anyway Like if the customers are paying and you're enhancing it, is it still legacy? Maybe right because it's on yesterday's technology Right, you don't have the skillsets available Let's say to make the enhancement sometimes or even maintain the system going forward I mean that you could turn that into a legacy system the other thing is put yourself In light of all your customers and say sorry all your competitors rather and say Where are we in terms of what we're offering right and if we're you know towards the bottom quarter of the What they're offering in terms of new languages new stacks new tech Yeah, we have a legacy system right I'll give you a concrete example if you don't have a mobile version of your app But you have a version that works on the web sort of works on the web You could get to a web browser and you do what you can That is a legacy system Okay, because everybody else is offering a system that is reactive right and so I think the definition isn't like a de facto. Oh here's a legacy system and that's it you're done It depends I think on on your own specific situation also the other side of it is if I was a product manager in that situation With a legacy system that customers are actively looking to pay for enhancements what yeah What am I gonna do whenever I ever gonna get the replacement for that system If I all I'm doing is taking their money and keeping it going and adding enhancements I mean in my case, I don't know if niche ever opposite like in my case You would be fighting with my management at that point I mean they're just like Brian How dare you Tell us that customers are still active and that I would be I would be forced in this weird position Of representing these customers that still Want the system to keep going or still want to keep Benning the system in different ways it with Open pocketbooks, sure, and my management saying make a lot more money if we took all your Developers and all your quote resources Because that's the way these folks would think quote resources All these spreadsheet item Move them over here to this other new hotter You know more hot fire thing that's got buzzwords and that my solution architects are all Gungho about right Right and you might also be fighting your salespeople by the way, right? You will be we can't be selling this old stuff you will listen to someone new system that we can actually sell right you're fighting them too I'm I'm I'm you guys are bringing up all kinds of scultons about Yeah, no, no, no, they're not they're not in or out there that they're like it's like pards of the Caribbean right now You're you're going through the boat and the skeletons everywhere right now They're in the water. They're on the road. They're in the boat with me. I don't even know what's going on if you're defending a working system like you'd like Make a note of the actual tactical Dollars that are going into the maintenance you're doing dollars coming in and the dollars going out So like you need to be real in line with the piano if you're doing if you're dealing with a legacy system here And someone else is doing the piano you're already sunk so at that point like I can't believe we haven't said this at all in the podcast before but at that point keep that resume Keep that resume updated because it's at the point where you're lobbying on behalf of the customers And there's no other voices in the room and the customers are kind of like no they're not on the call most of the time We only ask them when we want more money or whatever like Like you're you're gonna have a bad time you can see the early signs and your own people and your company calling you the trouble Um make sure you go out of your way to document when you deliver business value to customers Make sure you go out of your way to Promote your wins as a product manager in this case Or or the if you don't have a product manager right because you're like this like legacy development back in the house Kind of team go out of your way to promote your wins and the fact that you like you brought new revenue in And do that, you know, who's well positioned to do that in the company? No, I don't Your your health desk because they deal with your customers all day long And when they tell a customer we don't have that feature But we could consider adding it it might cost you and they go yeah we'll pay for bingo right they can they can evangelize that and then and then the final one here is to Calculate the real cost of replacement the accurate real cost The the real talk so I want to play the whole The real talk version of replacement of the system not like the happy path the real you know second third order effect all dealt with Set up so good luck with that good luck with it. So we're done here. That's what I'm saying If we've replaced this whole legacy system So let us know if there's anything we missed any edge cases that we missed in the comments Which takes me to the final recap of what we talked about. Chester's in fence I still am not sure what that even means, but I'm pretty sure it has to do with something with like We don't know what's on the other side of the fence. We don't look cross fence. We don't look through the fence We don't remove the fence. We don't remove the fence. Yeah, we don't care The big tripping point the big failure in my experience with cutting over legacy code is your high-level folks in the organization they never want you to go back and like do a full documentation of all the paths and everything They're like no, no, we're not gonna do that We're just gonna start over and start cutting over pieces one at a time and never looking back at what the previous system did So dangerous to do that. Why bother wasting time and money on that when we can just be focused on the transition or build a next new thing Right, right. Don't worry about all that stuff. That's already done That's already in production and for the most part it stands upright. Sometimes it falls over That's okay. Go talk to Billy Bob over the air and Mary over the air and they can fix it up Billy Bob and then we talked about why big rewrites always fail I was gonna say almost always but I'll just push this over the I just say always fail and then And then we talked about a couple other things spot spotting fake Modernization under the guys of Spend a bunch of money on nonsense and then we talked about finance, The finance side of this is the most insane part about all this is just like just somebody Doing a budget saying you know what you've done a good job long enough home That's quite enough of that I'm happy to retard Your value is going to zero if you're listening if you're listening on spotify or an Apple podcast the best thing you can do is give the podcast out I saw review And if you're on YouTube Comment down below on what you think about this podcast and any other new topics you'd like us to discuss in the future Plus while you're there, I can subscribe because there's always a happy puppy somewhere when you do that