I'm DROWNING In Legacy Code! AND There's No Documentation!

Transcript is auto-generated and may contain errors.

all right it is Thursday and I finally got my wife's SUV back so we're out of the X1 which is uh way better now than a real vehicle sounds good it's way better um okay got a topic for today it's going to a shorter drive cuz I'm partway to work sun is destroying me here um this one is going to be about working on Legacy code uh kind of getting into a company working in an area uh the sort of experts are gone or there's not a lot of documentation kind of inherited Legacy code um so we're going to talk through that quick reminder to folks if you want me to talk through different topics leave a comment if you wanted to Anonymous just find me on social media as Dev leader send me a message the more detail you provide the more perspective I

can offer up uh of course I will keep it Anonymous um there's no reason for me to not do that uh so happy to try and help if I can I think that's it let's do this um so I wanted to start this you know sort of thought process here by by mentioning like it's really going to be a huge part of your career as a software developer to be maintaining code okay I think that a lot of people especially getting into it don't realize just how much of their career is maintaining code and that doesn't sound super sexy I get it you're like oh man Legacy systems I got to do this but like um if you were always rewriting code like we wouldn't be iterating and building stuff uh uh to be more and more robust and handle different situations and stuff it's

it's going to be one of the like the thing that you spend probably most of your career on so um I wanted to remind you about that if you're not if you're either like new uh or you are you know aspiring to be a software developer this is just a reminder that if you're not focused on this and you're not thinking about this and your assumption is that you know anytime you go to touch code it's going to be building something new it's just not the case the exception to this could be if you are say doing um I don't know like you're a solo Dev or uh whatever you're doing like contract work where someone asks you to build something and then you hand it off and you're like and I'm not supporting this like I've built it for you here you go now

we're done like that's the end of the discussion um if that's how you set up how you want to do business that's obviously up to you uh but I do think that you know overwhelming majority of people that are listening to this and that are into software will find themselves supporting Legacy system so um this is an important topic I think and I thought it was a really good question because the framing offers some constraints right it's not hey I'm maintaining a legacy system how do I make it fun it's not a maintaining a legacy system how do we uh balance whatever it's there are no resources which is a it's a crappy spot to be in but it's also not uncommon so uh this can happen in a couple of different situations one is like uh say at a very small company if there's

turnover so say you're at a really small company and there's like one Dev who's building everything and I don't know like there's challenges or stuff comes up with this individual they end up leaving for whatever reason and now all of a sudden you have the one expert in the area who is gone so what do you do right he was too busy he or she was too busy building stuff not documenting it cuz why would they do that it's a small company they got to get stuff done right so they end up leaving now what right so oh we're not even in sport mode come on oh we're going to dial it up here this exhaust sounds very very good but if you're inside the car it uh BM BMW does does a good job of like sound ding I guess but for an SUV

it's very gurgly it's very cool um okay so if you're at a small company this could happen especially if there's turnover but it can also happen at big companies where if there's reorgs or people are kind of like handing off services or products or like we you know we got this thing it doesn't make sense for our team to own anymore like things have grown things have changed like here you go um now you would hope in this situation you still have people that are like yeah like we know what's going on my map is doing circles on me keep it keep it together Google um you would hope that at a company like the people are still around to be like hey man like I need help with this like give me some support you would hope to like if that was a product

that was built up over time there's documentation but one of the challenges that can happen here is like yeah there might be documentation it might be completely useless cuz it's outdated um I have been in a situation where a team was like here you go like we're kind of giving all this stuff over to you and there was a brief period where it was like yeah and we'll help because we understand and has to transition but like we're talking about areas that are built up over many years and it's like you got a few weeks worth of help before they're like screw off like we got our own stuff to do now so this can ha my point here is it can happen at big or small companies it's not uh specific to just one or the other so um if you're like oh well

don't worry I'll be at a big company or I'll be at a small company and I can avoid this like H maybe but I think it's good to be prepared for this kind of thing so there's no documentation and there's no people to support um the unfortunate reality is like uh it's a business business and things have to keep going and that's the end by the way this just because I'm passing this very much a tangent I but I need to bring this up cuz it's bizarre to me um I'm not a a Washington Native right I'm from Toronto and I live in uh just north of Seattle now I didn't know this was a thing and they're everywhere out here bik Baristas if I'm saying that and your first thought is what the hell is that that's exactly what my thought was and still

kind of is um there's these popup like coffee stands they're literally like a little Hut and they'll be along like not the freeway but like highways and stuff uh or even like on I don't know in commercial areas in parking lots and it's like a popup coffee shop but it's like girls and bikinis that give you coffee it is such a bizarre concept to me uh but also because there's so many of them out here I feel like someone's making a killing off this so like part of me is like hey good job for finding that like that's a really cool thing and then it made me think why is it only out here why have I never heard of this anywhere else so anyway if you're looking for a business idea apparently this works really well um but I wanted to share that just

cuz I passed one and I thought that might be kind of interesting for folks cuz I didn't know it was a thing so when you're maintaining Legacy systems like this the the reality and it's like the the hard truth is like you can't just say hey like I don't know and I guess we have to like just like wait like you have to figure things out because if the business requires it you have a product or a service that needs to keep going because that's what's making money if you just say nah we don't want to or no it's too hard like we'll just start from scratch turn that thing off we'll start from scratch where do you think like what are customers going to be paying for where's the where's the money coming from right if you have a live service and you're like

oh we just won't worry about it because we don't know it's not it's just not going to work especially if you're a small company right you're going to be screwed your company's going to be screwed it has to keep going now I think the person that asked this I think they probably understand that so I'm not directing this at them and trying to like lecture them on it I'm just trying to paint a picture here right like when we talk about building like projects and stuff hobby projects you get there's almost no constraints build whatever the hell you want right and it's good you can learn things but when we talk about business a lot of the times I think people have especially if people are newer to it um they don't realize that it's literally a business and people pay for getting value so

you have to keep things going because when the money stops coming in the business ceases to exist okay that out of the way let's go back to the situation and start thinking about what we can do like how can we action this now that we understand it's a it's a situation but it's also reality and it's going to be reality for a lot of people too so first thing I would recommend is like you want to start building up that documentation that doesn't exist okay so start trying to pay attention when there's issues coming up and we're fixing things in a certain area my recommendation would start to like keep a bit of an inventory of where some of the pain points are okay so from the perspective of the code if you're like hey we have a bug here again again and we just

fixed it and that caused another bug or there's something uh that was there before and we've discovered another bug whatever it happens to be if you can try to start keeping an inventory of roughly what areas of the code these things are in I don't mean like specific line numbers like that kind of thing but if you're like we got a module that um makes PDFs I'm just making stuff up we got a module that makes PDS we have we have a module that does authentication we have a module that does whatever um if the PDF thing is always causing you problems like this would be a really important thing to note because if you're thinking about hey we got this Legacy system once we start getting things back on track and understanding maybe that's something you want to go dig into maybe you want

to go figure out do we have to go rewrite that PDF module thing because apparently it's pretty problematic so an inventory I think is very helpful uh on the topic of inventories of things I would also recommend uh and this is something that I've kind of learned from being at Microsoft with live services for contexts prior to Microsoft I was building desktop software so we weren't pushing stuff uh to like data centers and stuff like that it was like shipping products and uh sorry I'm going to figure out where I'm going here this is isn't the normal way I take to work so I just got to pay attention um so coming to Microsoft it's now it's like live Services instead for the past four and a half years and something that's very common across all teams it seems or at least most that I've

interacted with there's this idea uh the term is Battle card but you could call them anything uh it's really just like scenario based information where hey I'm on call dealing with an issue here's like a scenario and here's how you approach like diagnosing it mitigating it uh root causing it fixing like all this kind of stuff right to give people guidance when they're on call trying to support the service so I would recommend starting to build that kind of thing up and this is going to be your first line of documentation and the reason I like this is because the reality is at least for a while as people are building up expertise there's going to be hitting the fan it's like un unless you just get really lucky and uh I don't think like hope and luck is a strategy I think that's something

that can happen but I wouldn't uh I wouldn't Bank on that um the the thing that you can do here is trying to understand like there are going to be problems and how do we try making sure that when the problems happen we can work through them so the first thing I mentioned was inventorying like problematic areas of code as you encounter them starting to build that up to build an understanding and the second part here is when there is an issue how did like try to put some steps together for how did we diagnose this how like what were the symptoms how did we diagnose it how do we mitigate it I'm trying to be very general here because I don't know if we're talking about shipped products versus live services this is has to be General how do we mitigate then how do

we root cause and solve things right so trying to put together that kind of stuff to start forming documentation I think is very helpful um I'm trying to think if there's it it depends how much work is being done on this stuff too like is it a legacy system that you you've inherited and like you just need to keep alive or are you going to start building on it more and more um so I have some different thoughts around this if you're just trying to keep it alive um my recommendation uh uh with anything where it's just keep it alive we don't need to keep building to to do more stuff you can't see what I see ahead of me but I'm merging onto a different Highway and like it's just solid it's terrible it's uh it's already after 10: in the morning so I'm

already like an hour after I started to work super early this morning so I'm not I don't don't really care but just like this is a situation man this is not good for traffic that's why we're on code commute though so if you're trying to build more stuff or let me go back if you're not building more stuff on Legacy systems I would say touch it as little as possible touch it as little as possible because if it's already working don't touch it document it understand it don't touch it when there's issues that come up fix them and try to touch as little as possible when you're doing it document it understand it root cause it all that stuff but touch it as little as possible if you're not trying to extend it and add more functionality touch it as little as possible okay the

value in trying to just say like hey like it's Legacy code we want to go refactor and rewrite it uh why if it's working why touch it as little as possible if it's an absolute show and it's constantly broken and you're spending tons of time fixing it I would say these might be different circumstances where you'd have to weigh out like how much work are we putting into just like trying to keep this thing from constantly being busted and you might say well we have to go refactor things now because we're spending so much time otherwise right but if it's not broke don't go wasting time trying to go make it better because it's not broken that's a really hard thing for a lot of programmers to hear because they go well I know the code could be better like yeah code can always be

better man it can always be better don't touch it you got other to do right there's other problems to go solve but if it is always broken and the cost of like the tax of maintaining it is very high then yeah you need to go figure out if you need to prioritize um rewriting this stuff refactoring some of it whatever it happens to be but that's goes back to my first Point around inventorying where some of the problem areas are and then you want to cross reference that if you are so the transition here is if you're going to be building on top of it right so you've maint uh you've inherited a system you need to maintain it but you're also going to be extending it now this uh this list you've been building up of problem areas you want to cross reference that

with where you need to be like adding functionality and features because when it comes to prioritizing someone's going to need to figure out where to spend the time pardon me um is it going to be like hey things are good enough right now let's add more features because that's going to allow us to get more users like from a business perspective factoring these things in or this bug is really problematic it's an issue for customers we got to do something about it right so someone's going to have to prioritize it and having information is going to be helpful let's get in the fast lane this thing's pretty awesome like the like the Mercedes it's also a V8 twin turbo so but the Mercedes just because of I mean like the style of the car like you feel like you're in like a a little rised

car this is like a big comfy SUV but it's like when when I'll put it this way when I was standing in the shop and the guy pulled it up and it was still kind of like in its cold start mode it sounded like I don't know it sounded like a huge tractor like chugging outside like it's it's pretty beastly but my wife gets to drive this one so it's probably nice and comfy for her she doesn't like driving fast or like she doesn't like if I in the car so it's really fun when I can drive this and do it okay so another thing that I want to talk about here is like some of the Team Dynamics around this stuff for like Legacy system so if you're in a situation I mean if you're a solo Dev and you've inherited this stuff it's

really challenging like you're going to have to build up the expertise unfortunately but I think that what you should plan for is that there will be other developers okay so my points around documenting things and building up that understanding building out battle cards to support the system call them whatever you want it doesn't have to be battle card um man it sounds good um the idea is that you're planning that in the future there will be other developers if you don't plan for this kind of thing what can happen is that when other developers come on great they get to go do whatever and guess who the expert is that has all the knowledge all the experience that is absolutely tied to this Legacy system because if they were gone it would fall apart it's now you so if you want to prevent this from

happening so that you can work on bigger and better things newer shinier things things that might be offering potentially new value to the company you want to make sure that you're enabling other developers to come into this okay people sometimes will say well isn't that job security if I know this thing and I keep it to myself isn't that securing my job yes and no securing your job and it's also sort of a death sentence for your career because you won't grow in your career sure yes you are the expert in this one spot the company needs you for this one spot if you're very happy just being attached to this one spot Until the End of Time congratulations if you actually want to continue to grow in your career experience new things work on bigger projects have bigger impact you probably don't want to

be the person anchored to one single thing unless that single thing happens to continuously grow and it's going to be an awesome experience cuz it's going to the Moon in terms of features and scaling up teams around it if you're in that situation that could be totally cool but if it's a legacy system that you've inherited odds are maybe not so I would say plan to make sure that you can have other developers come in and get ramped up fast now if you are joining oops about to lose this thing this mic if you're joining a team in this situation right and so you've inherited a legacy system and there's a few of you I would highly recommend um there's different ways to do this but if you have like I wouldn't just put one person on the Legacy system and saying hey Bob you're

the Legacy system guy sorry it sucks to be you uh in fact I would highly recommend putting everyone on I'm not saying full-time I don't know what other things you have to go build or whatever else but if there's a legacy system I would not make one person go do it I would find ways to balance that across the team you could do things like having if you had three people as an example you could have them each look at different core parts of this Legacy system this way they could each build up expertise in these different areas they could all approach what we were just talking about in terms of documenting understanding the system and then that way over time you could try rotating people in and sharing that knowledge but at least that method might allow you to go a little bit deeper

in certain areas that's one strategy you could keep everyone kind of shallow on it so that everyone at least understands a little bit but you're going to need to figure out how much support this thing needs goes back to the point I said earlier are you just keeping the lights on with this thing maybe it's already doing pretty good shit's not busted you got to keep the lights on you know get a base level of oops I spat get a base level of understanding make sure it's documented make sure people don't feel like they're falling apart when they have to look at it um you might even find to be completely honest that there's issues that are so infrequent that like even when there's an issue like a bug comes up or an incident and it's super painful you're like okay but it was painful

for like 2 days and that really sucked but it's 2 Days Every 3 years I'm just making up time time intervals here but like the my point is that there's always tradeoffs there's always tradeoffs it might seem stupid to say well we don't care to go invest time into understanding it making it better blah blah blah but like if you do the analysis and you look at the tradeoff and you're like okay so you want us to have like 20% less productivity to go support this thing understand it more deeply when it's doing totally fine and there's an issue once a year and that takes from a year perspective takes like you know 5% of our or yeah 05% of our time like it seems like a seems like a crappy tradeoff so like think about these things everything that we do in software engineering

is going to be some type of tradeoff right everything so I think that sometimes we look at things on the surface and it's like there's an obvious answer but but if you step back and do a little bit of an analysis you're like hey maybe not so I think it's good that we question these things right it's why it's also really helpful uh I was thinking about this when I was driving to the shop these types of talks for me are a really good opportunity to do like a bit of introspection and help me think about how I would convey these ideas to other people so um like selfishly it's helpful for me to go like think through these things number one cuz I get to think about them number two cuz I get to practice like talking and communicating them we got to switch

lanes here let me in buddy let's go um trying to think if there's anything else on the Legacy system part it's not easy right I want to acknowledge that like I'm talking about this this kind of stuff it's going to take time to build up the expertise and I think that ultimately you're kind of looking at this tradeoff of like are we just keeping the lights on for it versus are we continuing to build on it there might be some things we can think about here in terms of like say you have this Legacy system no one's happy with the architecture but we got to keep the like but we actually do want to iterate on it and like add more things um if you are familiar with Martin Fowler I believe that he coined this the Strangler fig uh the Strangler fig approach he's

I think he's also acknowledged it's a bit of a weird name um it's this idea that you can take different parts of the system and then like strangle them out so you start replacing parts of them without just like doing a full rewrite from scratch I really wanted to do that nice um so the idea would be you have this Legacy system in place place it's working it's got some hiccups whatever's going on right we'll park the doc documentation stuff for now cuz I've talked about that probably uh enough that you wanted to turn this video off already now we have this Legacy system in place building up the understanding and we're we're saying okay cool we need to start extending this we need to start doing more with this system you might realize that you have these areas where you're like we want to

extend it here but it doesn't really support that so with a Strangler fig approach what you're able to do is start building up the new implementation of things and then what you can do is like you basically have I'm going to use the word API here this is a loaded phrase because depending what type of development you do you might gravitate immediately towards web apis you might gravitate immediately towards like what's the function signature on the interface I mean this from a general sense just as a heads up so you can apply this at different different ways but you want to think about your API surface that you have and then say okay we're keeping everything else the same but behind this part of the API surface we're going to start calling into the new code here okay and what ends up happening is you

keep repeating this process over time where you're building out new things sort of behind the scenes behind some part of the API layer that you're dealing with and over time you start replacing all old code so you're sort of strangling out the Legacy code over time and this was something that like um if you read Martin Fowler's explanation on it it's a pretty cool um pretty cool pretty good explanation of how it works I think he coined it because of some fig tree or something that when he was traveling he was I don't know if it's actually a true story or not but he talks about how oh like this is how the tree works and like it's actually uh slowly like strangling out the other um sort of life form that it's competing with whatever so it's a cool analogy this guy's got to

let me in let's go here we go it's way better driving this thing the X1 man that X1 is trash when I put my foot down in this thing it goes in the X1 it's like I could put my foot down take a quick nap and then we start to accelerate um so yeah I would say if you have to go extend systems like this I would highly recommend you go do some reading on Strangler fig approach uh there's probably plenty of other philosophies around this I like the Strangler fig part because uh historically I'm not a huge fan of rewrites uh to explain this briefly like before Microsoft I worked at a startup and I mentioned this ear earlier when I was talking about you know keeping the lights on versus not um lots of people love the idea of going to rewrite something

cuz they'll make it perfect the next time which uh spoiler alert is um cuz nothing's ever perfect and odds are that you get to a point with your rewrite we're sure you've addressed some of the original problems but you have a whole bunch of other ones because that's what happens when we build software so people get it in their head they're going to make it perfect the second time third time around there's always to deal with so instead of just like pretending and saying oh we're going to build it perfect the next time designing software that can be extensible is super helpful because you never I shouldn't say never you less frequently have to go and do a full-on rewrite so if you're in a situation small company trying to keep the lights on need to start iterating you keep this Legacy system going you

don't say ah screw it we're burning it down we're going to go make a new one you keep it going and then leverage this Strangler fig approach where you can start building out new functionality and calling into it from the Legacy application and you do it piece by piece you might reach a point in the future where you have to do a larger portion of this has to be Rewritten uh but in my opinion you can keep things going for longer by not having to do uh a full rewrite this is nuanced of course I always say this there's going to be someone watching this who's like no you should just go rewrite it okay um there's going to be exceptions to everything I've absolutely seen code that has to be Rewritten or it's better to be Rewritten we weigh out the the pros and

cons and it makes more sense to do a rewrite so I'm not saying always and never cuz I think that's a trap but um from what I've seen in my experience so far in my career I would much rather keep things going than take down time if you have resources and it makes sense to go rewrite while you continue on with things might make sense not a lot of places have that kind of luxury let's see if we can get some good gurgles ready put the windows down for it I don't know if you can hear any of it maybe not whatever I tried certainly not backing up no gurgles but we can probably get a good cold start on the way home so with that said make sure you watch the next one this thing has a camera it's got the beeping cuz that

X1 had nothing okay that's it for today I hope that was helpful I got to get rushing inside here for a meeting I will see you on the way home thanks for tuning in take care