Fighting Technical Debt With Continuous Refactoring

Rate this content
Bookmark

Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt. In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

This talk has been presented at React Day Berlin 2022, check out the latest edition of this React Conference.

FAQ

Alex comes from Romania and works at Code Sandbox. He is also an organizer of JS Heroes, a community event based in Cluj, Romania.

Alex's talk focuses on the culture of refactoring rather than specific techniques. He discusses how to integrate refactoring into the regular workflow of engineering teams without disrupting product development.

The 'three pillars of refactoring' mentioned by Alex include practices, which define the goal or desired architecture; inventory, which involves assessing and prioritizing technical debt; and process, which outlines the steps to manage and execute refactoring tasks.

Technical debt accounting is a document used at Code Sandbox to track technical debts introduced during development, including their reasons, possible solutions, ownership, and priority.

Alex suggests making refactoring visible and rewarding within the team, ensuring it is treated like any other task, documented, and celebrated to maintain team motivation and awareness.

Alex advocates for refactoring, which involves making incremental improvements to the codebase, rather than rewriting, which entails starting from scratch. He believes refactoring is generally more beneficial as it evolves the existing codebase progressively.

The Code Sandbox team manages technical debt by documenting it in a specific technical debt accounting document, prioritizing it, and incorporating it into their regular engineering processes, ensuring it's handled continuously and transparently.

Alex discusses creating a technical debt accounting document, making refactoring efforts visible and rewarding for the team, and ensuring the refactoring process is resilient even during tight deadlines or lower priorities.

Alex Moldovan
Alex Moldovan
29 min
02 Dec, 2022

Comments

Sign in or register to post your comment.

Video Summary and Transcription

This Talk discusses the importance of refactoring in software development and engineering. It introduces a framework called the three pillars of refactoring: practices, inventory, and process. The Talk emphasizes the need for clear practices, understanding of technical debt, and a well-defined process for successful refactoring. It also highlights the importance of visibility, reward, and resilience in the refactoring process. The Talk concludes by discussing the role of ownership, management, and prioritization in managing technical debt and refactoring efforts.

1. Introduction and Background

Short description:

Hello, everyone. It's such a nice view to be in front of a stage after such a long time. I've been here before. I had a great time. So as Yanni said, my name is Alex. I work at code sandbox. I'm organizing JS Heroes. Our next event is May 2023. I want to talk today about refactoring. But before I start, there's this link at the bottom. Bit.ly slash Alex refactoring. You can find the slides there. You can also find me on Twitter at Alex and Moldovan. That's pretty much about it.

Hello, everyone. It's such a nice view to be in front of a stage after such a long time. You have to excuse my voice, the Berlin weather was not kind to it this week, unfortunately. But it's such a great city. I've been here before. I've been here at this conference in 2018. I had a great time.

Oh, yeah. So let's start. So as Yanni said, my name is Alex. I'm coming from Romania. I work at code sandbox. Anyone here use code sandbox? Nice. Alex. Nice audience. Cool. I also, as mentioned, I'm organizing JS Heroes. This is a community event based in Cluj, Romania. Our next event is May 2023. So I'm looking forward maybe to seeing some of you there as well. Come find me after the talk. We can talk more if you're interested in this.

So I want to talk today about refactoring. But before I start, there's this link here at the bottom. Bit.ly slash Alex refactoring. You can find the slides there if you want to follow along or if you want to find them later. They're already online. And there will be also after the talk. You can also find me on Twitter at Alex and Moldovan, while the platform hopefully still is running. So yeah, that's pretty much about it.

2. Why I want to talk about refactoring

Short description:

I want to talk about refactoring culture. I'm fascinated by why we haven't figured out how to refactor our code without impacting product development. We can build engineering teams and cultures around introducing refactoring as any other task. Understanding that it's okay to live with technical debt, we need to manage it. I will present a framework called the three pillars of refactoring: practices, inventory, and process.

Why I want to talk about refactoring or why is this talk about refactoring. I want to talk about refactoring culture. I'm not here to tell you ways of refactoring code or techniques to improve your code or improve your React components or frontend in general. I'm mostly fascinated by why we haven't figured out how to refactor our code, our code bases without really impacting product development.

I worked with so many different teams over the past years and especially with product teams. There's always been this problem of, okay, we accumulated technical debt, now it's time to do refactoring. So, you know, project managers, please step aside. It's time for the engineers to take the stage and they'll be working for one month rewriting everything, introducing a new framework or whatever just to solve this technical debt. I think we can do better. I think we can build our engineering teams and our engineering cultures around introducing refactoring and treating it as any other task on a project.

And this became even clearer to me a few months ago when we introduced this new thing in the code sandbox code base. So, we have this thing called a pitcher provider. Pitcher is our engine for running the editor. So, when you run the code sandbox editor, you have this pitcher thing that serves you all the data from the VM. And we introduced a new way of consuming pitcher data. So now what we have is a legacy pitcher provider and a pitcher provider, right? And that's perfectly fine. We never said, okay, now we have to stop everything at code sandbox and we have to focus on getting rid of the old way because we have a new way of consuming data. And I think this is really valuable. Understanding that it's okay to live with technical depth. You don't have to feel it necessarily as a burden. But you do have to manage it. So, actually this happened while I was preparing for this talk. And while I was also doing that, I realized that maybe the title is wrong. Maybe it shouldn't even be fighting technical depth but rather managing technical depth. So, what I'm going to show you in the next couple of minutes is a framework for how I think we can manage technical depth in engineering teams. And I'm calling it the three pillars of refactoring. Because, well, obviously it has three pillars. One is practices, one is inventory, and one is the process. And I'm gonna take them one by one and explain what I mean by them. So, first off, we have practices.

QnA