00:00:08.570
Hello everyone! This is my very first Pivot and my first time at the Weave. I'm pretty happy to be here. I want to thank all of the organizers and you all for having me here today. Olivia has been awesome these last 24 hours.
00:00:25.550
So, this is my talk. It's called "The Life-Changing Magic of Tidying Technical Debt." It's kind of a nod towards this lady here. I was talking with Sophia, one of the Pivot organizers, about her yesterday. She gave me a heads up and mentioned that maybe Marie Kondo isn't as popular in Ukraine as she is in the UK or the States.
00:00:44.270
Out of curiosity, I'd love to see a show of hands. Does anyone know who this woman is? Okay, that's more than I expected! Her name is Marie Kondo, and she has written a best-selling book called "The Life-Changing Magic of Tidying Up." She also has a really popular Netflix show called "Tidying Up." For those of you who don’t know her, Marie Kondo is somewhat of a global sensation.
00:01:06.289
She is a tidying expert, a best-selling author, and the star of her own Netflix series. She was even named one of Time Magazine's top 100 most influential people. Marie is famous for helping people around the world transform their cluttered homes into serene and inspiring spaces. She takes the whole concept of tidying to a new level in her book, teaching that if you simplify once, you'll never have to do it again.
00:01:41.840
She encourages us to examine our belongings and ask ourselves, "Does it spark joy?" This helps us decide what to keep and what to let go of. Kondo pairs this philosophy of mindfulness and introspection with a specified series of tidying lessons, which she calls the Konmari Method. It is known to be highly effective. Much like the talk I'm giving today, her books and Netflix show are about much more than tidying; they are about being intentional about what you choose to own and how it impacts the way you think and perceive the world around you.
00:02:19.639
Technical debt is very much like the clutter we have lying around our homes. While some people are fortunate enough not to work on codebases with technical debt, for many, it plays a significant role in slowing down development. As Marie Kondo would say, "Technical debt does not spark joy." So, the plan for this talk is to begin by examining what exactly technical debt is.
00:02:54.299
We will discuss clean code versus tidy code, and then look at how we can apply the Konmari Method to tidying away technical debt forever. Not too long ago, I stumbled across a really interesting paper about the "Big Ball of Mud" phenomenon, written in 1997 by Brian Foote and Joseph Yoder. I highly recommend giving it a read—it's both funny and interesting!
00:03:29.400
The paper defines the "Big Ball of Mud" as sprawling, complex, tangled spaghetti code jungle. Does this architecture sound familiar to you? It should because big balls of mud are very common. We all know these types of systems—they're systems in which many of us work, systems that many of us use, and they may even be the systems you are creating right now. But how do they come into existence in the first place?
00:04:05.340
The paper explains that, due to business pressures and high developer turnover, as well as degrading designs, the big ball of mud is both inevitable and optimal because software economics ultimately conspires against us. Especially in the early stages when time and money are in short supply, we tend to ignore architecture and performance and focus instead on features and functionality.
00:05:09.120
As a result, the structure may have never been properly defined from the get-go, or it’s been eroded over time by unchecked growth, an onslaught of changing requirements, and repeated quick and dirty fixes. This approach often leads to one-time-use scripts, quick fixes, and silly workarounds finding their way into the production codebase. When we neglect it, our team members tend to neglect it too, because neglect is infectious.
00:06:02.729
Common sense tends to go out the window; new team members, for example, start to extend throwaway code. Before we know it, our code becomes that big ball of mud. To tackle this problem, we need to make a commitment to ourselves that we will not neglect the code. This commitment involves actively seeking out best practices and tools to help us achieve that.
00:06:59.670
One of these tools is clean code. I won't delve too deeply into what clean code is, as a lot has been said about the subject, and there are numerous resources readily available. Just to name a few, you have Sandy Metz, Kent Beck, and Robert Martin— all pioneers in the field who contributed towards clean code best practices. For those who might want a quick refresher, let's briefly cover the main ideas. Clean code involves attaining 100% test coverage, writing short reusable methods, choosing meaningful names, and practicing object-oriented design and refactoring.
00:07:38.160
However, while clean code principles can significantly tackle the problems associated with the big ball of mud, they only get us partway there. I work at a company called Peg, which is a platform that connects brands to prominent Instagram stars. Five years ago, our business was relatively straightforward. Fast forward to today: our business now needs to support not only Instagrammers but also their representatives, such as talent agents and managers.
00:08:27.270
As a result, the system has become increasingly complex due to the introduction of various subscription plans. As the business grew, we hired customer success and sales teams, which necessitated additional analytics and third-party integration, complicating the code further. Let's rewind back to 2014 and take a look at what one of Peg's endpoints looked like.
00:09:08.310
This is a simple create action for a users controller, which is responsible for setting up that user when a brand signs up for the platform. Note how simple it is—just two lines of code. Now, fast forward five years with all the new requirements. This is the same controller endpoint. Don’t even try to read this; you could do some serious damage to your eyesight!
00:09:41.810
So, what happened? Developers over time began to add to those two lines of code. This didn’t happen overnight; it took years and contributions from many different people. What started as a simple user type slowly increased in complexity as we began needing agents and managers to sign up to the platform with special invitation codes.
00:10:15.800
In addition, various analytics tools were integrated, which required sending specific server errors to Airbrake, capturing each individual login in the database, routing new email addresses to third-party marketing platforms, setting up Slack notifications, and confirming product tours on the front end had been completed. I apologize for showing this to you again, but this code violates every single law in existence. It's an abomination that should never have been allowed to grow so large.
00:11:15.400
While this is an extreme example, the point I want to illustrate is that we can apply clean code principles to significantly improve this. For instance, we can move various bits of logic into respective models, clean up our variables, and add tests. However, there remains one flaw with this code: the underlying complexity still persists.
00:12:10.120
We can modify the appearance of the code, but we haven't actually removed any of the complexity, which is what tidy code is fundamentally about. Tidy code deals with making tough decisions about what to keep and what to discard. We need to question the underlying business decisions regarding unnecessary complexity in the codebase and feel confident about deleting things.
00:13:10.329
This is how we tidy—by implementing both clean code and tidy code. It’s about embracing the idea of being the Marie Kondo of code. To gain further inspiration from her tidying method, there are two main pillars of the Konmari Method that I believe are crucial for achieving lasting tidiness in a codebase: empathy and discarding.
00:14:25.900
When we think about technical debt, empathy might not be the first concept that comes to mind, and I realize that it could be surprising to discuss a soft skill in the context of technical debt. However, there is a strong correlation between messiness and shame. For instance, when my parents visit me in London and my home is a mess, I feel stressed and anxious about it.
00:15:45.270
Similarly, if I’m drying laundry and friends come over, I get embarrassed if they see my underwear lying around, which leads me to hide it away. The coder experience can be quite similar. When onboarding new team members, there may be parts of the codebase that you don’t want them to see. While working on legacy code or code others have written, it can be quite discouraging to shame them for the quality of their work.
00:16:53.950
Writing imperfect code is often a reality of what we do, so empathy is crucial in ensuring that someone's work is treated with kindness and respect. If someone is reviewing a pull request, that individual may feel anxious about code quality. Think about your own experiences when reviewing pull requests or dealing with legacy code—how do you approach others' work?
00:18:10.000
Moreover, we have all, at one time or another, had the experience of looking at a piece of code and thinking, "WTF?" This reaction can make people defensive, triggering stress responses that can hinder productive conversations about improvement. So, if you are in a position to help reduce technical debt in your organization, avoid being overly harsh or critical—bring empathy and kindness to everything that you do.
00:19:50.020
Without empathy, the practical techniques I'm going to discuss later may not be effective. To foster a culture free of technical debt, we must practice empathy daily. In 1999, Andrew Hunt and Dave Thomas wrote about the Pragmatic Programmer, followed by Chad Fowler’s The Passionate Programmer in 2009. Much of the content from these classic texts remains relevant and holds up even decades later. We've identified pragmatism and passion as important traits in our professions, but I would go so far as to argue that empathy is the most essential skill we can add to our tool belts.
00:21:51.000
I believe that 2019 should be recognized as the year of the empathetic programmer. Empathy is necessary for building better software and creating impactful teams. Without it, we risk contributing to that big ball of mud again. Returning to the Konmari Method, the second pillar is discarding, which is arguably what she is most renowned for.
00:22:24.000
When Marie Kondo teaches us about tidying, she provides various techniques for folding clothes and organizing belongings. However, we could spend our entire lives organizing items without any real change unless we eventually start throwing things away. It’s completely analogous to the development of code; developers can spend valuable time refactoring, applying test-driven development, or abstracting complexity, but ultimately the complexity will remain unless we start deleting it.
00:23:00.080
As the saying goes, "Deleting code is good because all code is bad." What I mean is that as developers, we love to write code to deliver value—that’s the job we were hired to do. However, the more we code, the larger the surface area becomes for potential breakage, which increases maintenance costs. Essentially, while the feature value we provide is crucial, the code itself is a liability.
00:23:57.460
We want to maximize the value of features while minimizing the amount of code we create. If there's a poor ratio of code to features, it indicates a technical debt problem. If we understand that less code is better, then deleting code should be a major aspect of our work—just as important as writing code. I love the feeling I get when I create a pull request where the number of lines removed exceeds the number of lines added. As Marie Kondo would say, it sparks joy!
00:25:01.000
Code deletion should be celebrated. Just as discarding unnecessary possessions can be challenging, deleting code can also be tough. We often find ourselves attached to our code and hold various emotions regarding it. This attachment can cause distress when others want to modify code we have written. It’s important for us to be empathetic in these situations to understand that others are doing their best.
00:25:54.609
The second thing that may prevent us from deleting code is uncertainty. Sometimes, we encounter code that is commented out, leading us to wonder if we will need to revert back to it in the future. This uncertainty can cause confusion, and to combat it, we can use useful tools like dynamic analysis to identify dead code. Furthermore, fear may also keep us from deleting code if we encounter intimidating code we don't fully understand.
00:26:54.350
Instead of backing away from the daunting code, we should seek to understand it by checking commit history and asking questions. Ignoring complex code only perpetuates an untidy codebase. The fourth barrier to deleting code is the belief that we may need it again later. This kind of thinking leads to clutter within production codebases. Instead of retaining unnecessary code, we should rely on source control, allowing us to store snippets that we might want to revisit later.
00:28:00.180
Labeling our deletion commits clearly will make it easy to recover deleted code in the future. Lastly, a significant frill which may deter us from deletion is the sheer size of the codebase. The key to addressing this is to draft code that is simple to delete from the outset. Begin by refactoring large areas of code to decouple various dependencies. Once that is achieved, it becomes easier to discard unnecessary components.
00:29:55.060
With this mindset towards deleting code, you'll start to appreciate the freedom of a leaner codebase. By recognizing that technical debt becomes less of an issue, you can handle new developments that convey imperfection without hesitation. When someone else comes across your work, they should feel uninhibited in deciding whether they want to delete anything without feeling anxiety about breaking existing functionality.
00:30:53.960
As we discuss these various techniques, my intention is for you to embrace the idea of enjoying code deletion, if you don’t already. Once there is less code, you can truly appreciate the remaining code’s quality. With the noise and uncertainty diminished, you'll witness the many benefits of a well-organized codebase.
00:32:04.860
The Konmari Method encourages us to express gratitude towards our belongings before we let them go, which means thanking each item for its service before throwing it away. The next time you tackle technical debt, take a moment to appreciate the code for its hard work, then hit backspace and let it go. This is the life-changing magic of tidying!
00:32:36.180
Thank you!
00:33:08.470
Afterwards, questions from the audience. Is this still working? Yes?
00:34:32.760
Over the years, we’ve tried a ton of different solutions. At the moment, the company is upgrading many of its technologies. We have found that running two simultaneous builds has been the most successful approach for tackling technical debt by essentially rewriting our software and eliminating features.
00:34:59.170
For example, we used coverband, a Ruby gem that helps find dead code, and Skimlight to discover which endpoints are in use, leading to a reassessment of functionalities. So, our approach will likely evolve with the new codebase.
00:35:31.780
A question was raised about my experience using Rubocop and its effectiveness in maintaining clean and tidy code.
00:36:17.350
I haven't personally used Rubocop, but it apparently employs community best practices within Ruby to identify sections of your codebase that are violating those standards.
00:36:56.260
When it comes to fostering empathy within the team while reviewing peer code, that's been crucial. Moreover, I promote viewing code from the perspective that it will eventually be deleted. This mindset can motivate clearer and smaller coding practices.
00:38:49.500
Another audience member asked about a significant failure that occurred due to code deletion.
00:39:38.760
I have a brief story regarding a time when, despite having excellent test coverage, we inadvertently deleted the user model. Due to oversights, the tests that were supposed to cover those functionalities passed without a hitch, allowing us to release a version of our application without that critical component. What a disaster! So that’s a noteworthy cautionary tale when it comes to code deletion. Thank you all! Let’s give Sroop a warm round of applause!
