 Hi, everyone, it's great to be here. This is actually my first time back talking in person since 2019. So, right, we're getting back in the groove. I forgot my emotional support chapstick, but I did bring my emotional support water bottle. Hold on, this is the time when my computer wants to update. Salesforce never stops. OK, so again, I'm Sarah. I'm an engineer on the front-end team for Heroku. We've actually got a lot of representation from the team today. We've got the whole crew in the house. If you find anybody, please say hi. We also have a table out back, so I hope you all have had some time to go back and stop by. Before I joined Heroku, I actually spent the first part of my career with the federal government and the last part of that at the General Services Administration, or GSA. I also work remote out of Dayton, Ohio, and I'm really passionate about developer experience, and that's one of the things that led me to join Heroku. During my time as a Fed, I saw a lot of neglected projects. Every time there was an administration change or a leadership change, someone's pet project got shuffled around and kind of lost in the system. And here's a good example. This is usability.gov. This screenshot is actually from July of 2013, so 10 years ago. When I was at GSA, I actually owned this product, so it's kind of my fault that it's not updated, sorry. But none of us really had time to work on it, and leadership never really made it a priority. And that happens for a lot of reasons, and it happens all the time. So here is, for fun, a screenshot of usability.gov from earlier this week. Sorry, again, visually not a lot has changed here. And maybe a couple of boxes have moved around, and I would absolutely put this in the neglected category, unfortunately. But this doesn't just happen at the federal government. I would probably wager that a lot of teams here, if you've been around for more than a few years, have some neglected projects in your back pocket that maybe you don't wanna pull out and look at too often or pay attention to. And at Heroku, I will admit, were no exceptions. And that's why I'm here today. You can see I am going all in with the medical theme, so excited about that. And here is a quick overview about how I'm gonna break up this talk today. First, we're going to take a look at evaluating old projects for viability. Is it something you wanna breathe new life into or not? And then we'll take a look at, if you do decide to revive a project, some ways that you might go about updating it. And then I'll just finish off with some tips. Oh, before I get started, though, I've heard this question a lot over the past two days. And the answer is yes, we do use Ember. We have been using Ember on the Heroku front end team since about 2015, I think. And so, just getting that out there. So, like I said, we've been working to evaluate a lot of our old projects for viability. We've had a lot of change within the Heroku organization. If you don't know, we're also owned by Seralsforce. So there has been a lot of kind of ebb and flow about the priorities and what we work on and kind of what we set aside. So I have collected just some questions and kind of categorized them into three groups to just better organize them. And that's gonna be the groups of the team, the customer and the tech stack. So first, taking a look at this from the team lens, here are some questions that you might wanna ask yourselves. And the first one is, do we have the time, skills and heart to keep this project going? And I think that heart piece is super important. Last year on our team, we had a member who was the SME for a project and really didn't want to be. They didn't have the drive to really properly give that project the care and feeding that they needed. And so eventually they moved on. And then this kind of takes me to the next question, could we bring on folks who would put in the time and effort and have the heart to keep that project up to date? And that's actually what we did on the Heroku front end team with our command line application we brought on to new staff to specifically focus on that product and work to get it to a better place. The next question, would our time be better spent on other priorities? I think whenever you are considering where or whether you want to work on a project and spend time and effort into it, you have to consider also on the other hand what is kind of being set aside. Every technical debt decision is also kind of a business strategy decision. So you have to keep that in the back of your mind. And then the last one here, is there another team with more resources that could handle the upkeep of this project? And I think this is one that folks don't consider often enough. It's one we actually considered on our team and we were all able to offload a project to another team and get it out of our hair, which was awesome. From the customer or product lens, you might want to ask the questions, is this still being used? Why or why not? We actually had another project on the front end team where we know we were going through our evaluation and found a project that hadn't been updated in four years. So that sounded like easy pick-ins to put it on the archive list. And then when I actually went to take a look at it, it turned out folks were still using it. It was still giving value. And so you have to consider that. The next question is, are we still solving the correct problem and is that meaningful? The product you developed five or six years ago might have been perfect for whatever product or whatever problem you were solving at that time, but then you need to consider, is that still valid? Is that people still care about? And then last here, who is doing this better? Oftentimes we create things and kind of move on and then other people will come behind us and create something else. Is that something else better? And do we have the passion to bring our project up to that level, up to par with them? Or do we want to let them have the space? And sometimes that's okay. One thing I wanted to add in here was to be sure and start with metrics for the things that you're considering. It's important to actually identify the ideal metrics to answer the questions that you have, but not try to shoehorn the numbers into answering the questions the way you want them to. Let's be realistic. And a lot of times you usually have both internal and external metrics available to you, so consider that. And then if you don't have any metrics to answer the questions that you have, then consider taking three months or six months to spend the time gathering that data so you can make a better, more informed decision. From the technical lens, again, we have this question of, do you have the skills on your team to bring the project up to date and keep it that way? And what about onboarding new contributors? Within our team on the Heroku front end, we have a lot going on, as you can see. We've got React, Ember, Phoenix Framework, Elixir, there's some GraphQL somewhere that we try not to look at. It's a lot. And that makes it hard to onboard new people. There's a lot of things to learn. If you focus on one thing, you're not really learning the other thing, and there's just too much complexity. But that is definitely one of the things that we are working into our long-term plan to reduce that complexity in a unification plan and ultimately offload some of these frameworks and projects. So one other thing you also need to consider is a technology outlook. Most things around us will eventually experience decay that might be the car or the bus you took to get here. It's gonna be the phone in your pocket, the laptop sitting in front of you, and your software architecture is going to decay as well. I actually read a couple studies lately that said software architecture debt is worse and more impactful than just regular coding tech debt. And I think probably everyone here by now has heard the combos around is Ember dying? And for us at Heroku on the front-end team, that answer is no. We're actually moving away from React and Ruby on Rails and investing more into Ember. And we found that maintaining and updating Ember is much easier than with React and it's easier to onboard new staff too. We love that you can make incremental changes without having to kind of stop the world like you might have to with React and that can be a big lift. And so that's why we want to expand our time and skills in expanding the Ember code base. So the outcomes from this phase could be update the project if you decide to save it, archive it if you decide it's not something that you wanna pursue or offload it to another team. But making this decision is not really black and white and the choice doesn't necessarily have to be to keep it going 100% or just bury it. There's a lot of in between there and you have to consider within your team, within your organization, what that looks like for you. So next we'll talk about updating the project if you do decide to revive it. One of the first things we did was to take an inventory you want to identify all the things that you are actually responsible for and take what you have and where you want to be and use that to develop your incremental milestones along the way. And working on kind of an endeavor like this, it can be helpful if you use a sort of maturity model or framework to help guide your thinking. This is actually a maturity model from GitHub and they published this back in I think 2016 has not been updated since, it's fine. But this really closely aligns to what we've been doing on the Heroku team. And so I wanted to dive into that a little bit. Level one is are minor dependencies updated? Have you satisfied your security bulletins? And I think another one to add here is have you evaluated and gotten rid of dependencies that you no longer need? I feel like we're adding dependencies maybe a little more than we're removing them and folks need to take a step back and do that as well. One technique that we use to kind of tackle this level one scenario for our applications is something that we call Big Thursday. Every once in a while on a Thursday we'll get the whole team together and split up into groups. Those groups are usually based on tech stack. So Ember, React, Elixir is kind of usually how it falls. We'll use a Kanban board in GitHub projects and try and just tackle as many of these kind of low level quick hit dependency updates as possible. Level two here is major dependencies are on a long term supported version. We actually put together a whole project recently with a small team to review all of our projects and get them up to an LTS version we were happy with. We literally called that project supported versions upgrade. So the rocket science there, but they got it done. For us that work meant updating things like Node, React, Ember, I think Redis, Postgres, Lerna, all the things. So the team got together in the batching of those similar things in order to move that along more quickly. Level three is the project well tested and that can mean different things to different teams. So you can figure out that for yourselves but the example I wanted to talk about here was when we updated our dashboard app to use Ember Q unit instead of Ember Mocha, we decided that we wanted to move to a testing framework that was fully supported. And so that was another project that we put together. It was a bit of a longer term project because we have a lot of tests in our app and I had the pleasure of working on that. It was super fun. Well, we did have a code mod to help out there so I forget who made that but thanks. Level four, so is your code well documented and organized? Well enough so that a new person can make sense of it and understand your expectation for contributions. I think a great first test of documentation is to onboard a new person and just set them for you to get a project running locally and on their machine without extra help and to me that's kind of the minimum bar for documentation like somebody else needs to be able to use it. And when I worked on code.gov we actually put together a research experiment to get folks to come and use our documentation we recorded it and took notes and wanted them to see it so they get our open source project up and running and that was super insightful and led us to a lot of documentation changes. And then after that, is there enough for someone to put in a PR according to the standards that you want them to put that thing in? So some things to consider and build from there. And then level five repeatable work is automated. I liked what we just saw from Flores who had a couple bots that they had created. I think the linting bot was awesome. So that was good to see. And end goal really is to have humans touching less things on a regular basis. So if there are repetitive tasks that can be handed off to a bot, then let's do that. And we've actually been using GitHub actions on our team to help with some of that. And then here I'm just kind of summarizing again some of those techniques that we mentioned, but they're just organized from kind of smallest time commitment to larger time commitment here. I think the first one I didn't mention yet was opportunistic improvement. So if you do nothing else as an individual contributor when you're in a code base, you can leave it a little better off. So take the opportunity to maybe just make one small change and make it better than where you found it. I talked about Big Thursday in batching, larger focused efforts. Oh, the last one was a multi-phased effort. And our command line application is actually going through a multi-phased effort to get up to date to where we want it to be. And I think that's a three or four quarter effort, long-term plan, RFC involved, a lot going on. So glad we were able to get leadership to approve that, thank you, Katie. And that's another thing that you can consider. And so you've got a whole kind of spectrum of ways that you can tackle things like this. It's also really important to get organized and ruthlessly prioritize the work. I read this story in a book where some folks had used some sort of algorithm or AI to evaluate their code base and it spit it out and said, it will take you 4,000 years to cover this tech debt. That's unfortunate, but maybe not surprising. And so it is doable, but especially when you have larger kind of overwhelming things to think about, it's really important to consider how you're going to ruthlessly prioritize, maybe start small and work incrementally and then just take small bites so you're not feeling overwhelmed and look for the quick wins. That's something I kind of like to do in anything. I am the type of person who gets a lot of energy from those quick wins. So whenever I'm starting something new, I kind of want to consider what's the low hanging fruit and what can I accomplish really quickly to feel that excitement and feel that momentum. So you've got this big list of prioritized work. How do you actually convince leadership that spending time reviving neglected projects is worth it and how do you convince your team to get excited about that work? And earlier this year, I saw a talk from Alex Smoldovan at Code Sandbox. I think it was the Tech Lead Conference and he gave this talk called Framework for Managing Technical Debt. He had three rules that I think really helped to answer this question. The first one is make it visible. You can't really refactor in the dark. You need to make sure that your entire team knows what's being planned and done and that other teams know what you're doing as well. You want to be very transparent and work in the open. The second is to make it rewarding. Teams need to get a sense of success from refactoring the same way that they do from shipping something. So consider, like I said, what immediate wins might be personally motivating to folks like removing code that doesn't spark joy or just making a project easier to onboard too. That's something I like to do. And then number three, make it resilient. How can you make sure that we don't get into this place again and have to spend time and money doing that work all over? Like nobody wants to think about that. Nobody wants to do it again. So leadership especially does not want you to spend money twice doing the same thing. So have a plan for that. And then for my last section, I have just a few tips to help you if you are updating a project, help keep you from getting to that place again. So I've got three tips. Document decisions, celebrate and create accountability. You want to document the why for the decisions you make first of all, how did you come to that decision? What were the trade-offs? Anything helps. I have in my years in my career have picked up a lot of old projects from folks who might no longer be on the team, no longer are in the company or at the agency. And anytime you can just write down why you made a specific decision, it super helps the person that who might come after you. Celebrate, set time aside to share and celebrate any wids. We do this on our front-end team and we actually have once a month a team brunch where we get together and chat. And last month we actually shared and celebrated some of our wins on some recent projects. So that was super fun. It's also good to track progress and share out any improvement metrics you might have like number of tests added or how much of build time was reduced. Numbers can be really motivating and leadership loves numbers of course. And then the last one here is create accountability because I wholeheartedly believe this. When everyone owns everything, no one owns anything. So one thing we're actually doing is moving to kind of better organize our products and organize our team to kind of split out responsibilities. So we do have more of a sense of ownership for those things. And finally, I want you to be realistic. Like please be realistic with yourselves. If you figure out that something isn't meeting your expectations, then it's okay to go in another direction. It doesn't have to be full speed ahead. This is what we decided, so we're gonna keep going. Take a step back, reconsider and adapt and adjust. And then I would also add in here, iterate and experiment. You wanna keep the vision for your change in mind while kind of changing out the tactics and the strategies to get you to that vision. This is my favorite piece of advice. I try to do this in all parts of my life. And this is the last thing that I'll say. It's important to save yourself from yourself because you might be that programmer six months from now or even six years from now that has to come back and work on this application. You might have to pick up where you left off. There's nothing worse than like picking up a piece of code and being like, oh, what is this garbage? And you wrote it. So let's help ourselves out. Let's help each other out and consider what you can do now to, if nothing else, just help your future self. Thank you.