If Marie Kondo were a software engineer: an idea for a refactoring approach

Every programmer I have ever talked to or worked with, had at least some experience with dealing with legacy code. Like our houses, our projects slowly get filled with things we never really wanted but somehow ended up at our side, things that served us great at one point and then were left forgotten somewhere in a corner, or things that we are attached to emotionally and having trouble letting them go, even though they stopped serving any purpose.

Nowadays there are endless sources – books, blog posts, online discussions, you name it – covering topics of code refactoring and dealing with legacy code.

Programmers are by nature (usually) logical and pragmatical beings: our code has structure, our working processes have structure, and rarely we look at our work from a “warmer” perspective, that is, the one where joy or gratitude play a role.

Marie Kondo is a world-known consultant on the topic of tidying up homes. She became very famous after releasing a book “The Life-Changing Magic of Tyding Up”, and even more when she got her own Netflix show “Tidying Up with Marie Kondo”.

Her method, named simply by her name, “KonMari”, claims that, the one who follows it, will only have to tidy up their space ONCE. What happens after that is only maintenance, because by following this method, one creates an environment that they actually always wanted and that fits their preferred lifestyle.

Feelings and auto-reflexion are crucial in this method, as she makes her customers to start being mindful of their surroundings, to start thinking about what they really want with their lives, and to start being aware of all the things they own. The big accent is on joy: throughout the process, one has to constantly ask themselves what is it, that brings joy to them.

The intention of this blog post is to look at the code refactoring topic and try to make a connection to the method for tidying up provided by Marie Kondo. Ask yourselves now: is it possible to add a bit of sentiment to our code refactoring? Aren’t we just humans working with other humans, and we all make mistakes or poor judgements sometimes, especially if under pressure? Can we take this into consideration when dealing with old code? Can we imagine to look at our code and say:  “This sparks joy for me”?

Marie’s methods & code refactoring

One of the central ideas of Marie Kondo’s philosophy is that every object one posses, has to have a reason for its existence. The reason for existence is not always purely functional: here lies the big surprise – the reason is determined by asking yourself a question: “does this object spark joy for me?” She claims that everyone is able to answer this question for every single object found in their homes (but she also gives a lot of tips on which objects to start with first, in order to have it easier in the beginning of the process). All the objects that “don’t pass the test” are supposed to be donated, sold or thrown away.

The idea behind this is that every person should live surrounded by things that reflect their true nature and preferred lifestyle, and by living like this, every day becomes pleasant and the person becomes more content. 

Can we do the same thing, but with our code? Take a piece of legacy code you have to work with, examine it, ask yourself a question “does it spark joy for me”?

Naturally, we cannot simply delete everything in the codebase that doesn’t make us happy. But, there are steps we can take to determine whether we should keep or discard parts of the legacy code we work with.

Step 1: Decide to tidy up

Not all old code needs to be refactored or deleted. It is also often the easiest to say something has to be completely rewritten or undergo a major refactoring, but in reality development teams are rarely given such an option. Marie’s customers do tidy up the whole house – but they don’t remove floors, walls or repaint the whole interior. They keep the house structure as is, and deal with the things inside, that are scattered, that are messy and that stand in the way of a happier everyday life.

Therefore we could, instead, use this step for a thorough examination: what is it there in our (old) codebase, that makes sense for us, now, to deal with? What can we touch and make better, what can we get rid of, that will bring value to end customers, satisfy our stakeholders, but also make our lives as code maintainers, easier? What is doable with the resources we are given?

Sometimes, especially if you’re in the same company for a longer time, it is even your own code the team decides to get rid of or fully refactor. So what! To be able to admit your old code has to be retouched now, only means you’re a better developer today than you were in the past.

Sometimes it is the code written by people who left the company in the meantime. More times than I wanted, I heard developers saying “look what X or Y did, it is such an ugly code”. Maybe even I myself said it sometimes. Throughout this step, it is important to keep in mind a set of beliefs we often use in our retrospective meetings, which is also called “the retrospective prime directive”, and it goes: 

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

I think the prime directive can definitely be reused to this step of the code refactoring too, where we should always be aware that code is written under various circumstances and that most of the time, the author of it really did their best.

As part of this step, it is also important to start establishing the right mindset, to get all team members on the same page. What is the purpose of making pieces of our code better, if soon we’ll repeat the mistakes we addressed in our tidy-up sessions?

In tidying up homes, one example could be that every member of the household never ever “hides” the unwanted pieces of their wardrobe in the back of their closet, but rather prevents the mess from happening again by simply avoiding big sales or buying out of boredom, which makes them end up with unwanted piles of unworn clothes again.

Step 2: Visualize your ideal lifestyle

In the book, one of the protagonists, when asked this question, claimed she wants to take a soft bath every evening after work and later enjoy aromatherapy while doing yoga on her floor. Yet her floor was completely filled with magazines and clothes and so she ends up being miserable with her life.

When refactoring, we could translate this to following questions: what do we wish to accomplish with the refactor? How does our ideal day of developing software looks like? What would be ideal way to debug, to build the solution?

This requires some careful thinking and communication between team members. Possible answers could be:

• My local build process is fast and therefore making me do changes in code faster
• I do TDD as it is a proven way of writing good pieces of software, and knowing that future changes will be easy to implement makes me feel calm about it
• Our build process is reliable, catching issues on the go, and I feel safe to deploy to production multiple times a day or week, stress-free

Once there is a clean vision, it makes it easier to go on with the refactoring, as whenever there’s a decision to make, you can always ask yourself a question: does it help me create that lifestyle / workstyle?

Step 3: Finish Discarding First

Probably the most famous part of KonMari method is taking every single of your possessions in your hands, and asking yourselves: “Does it spark joy?” If it does, you should keep it, if not, say “thank you” and get rid of it.

The main difference to other tidy up techniques is that we, instead of deciding what to throw away, focus on what to keep.

It should be fairly easy to identify what does not “spark joy”. Those are the parts of the code that we struggle with often, that give us headaches, that keep coming back throwing at us different bug each time. Identifying these parts should help us to know what to focus on when refactoring, and what to keep as it is.

Understanding what does bring joy in the codebase, can help with the overall satisfaction of the team. There are for sure parts of the code that are products of well-done pair programming sessions, or maybe some cool algorithms that solve problem on a fast and elegant way. It could be a good practice to find out what these parts are and to decide to keep them.

Step 4: Tidy by Category and Store Things Where They Belong

This is a fun part in the book or series, because Marie makes her customers gather all the items from the same category (clothes, books, papers and komono) and pile them on the floor or the bed.

It works well because if one goes and tidies, for example by room, then they will inevitable stumble upon things from one category in multiple places, and that complicates the process. Having it all on the same pile also gives us the feeling of how much we own, and what we really want to keep.

Now, we cannot take hundreds or thousands of lines of similar code and pile it up on the floor. 😉

However, in the big and old codebases, it is often possible to have similar things scattered around. Fortunately, we have plenty of ways to put similar code into categories, being folders, modules, introducing a naming convention, etc.

If we go into more detail, inside functions or objects, we could remind ourselves to always try to follow the separation of concerns principle, and have function does only what its name says, for example. 

It is like having a drawer for socks only, but you get very busy or stressed, and that one time you put a T-shirt inside. You don’t have time to deal with it, so it happens again.. Soon you end up keeping some of your T-shirts inside the socks drawer, but you also still keep T-shirts in their own, T-shirt drawer. Doesn’t that sound like a little bit of a mess? Of course, it is not a real case for concern, but if it happens on every shelf, drawer, closet or desk you own, you can imagine how you house could look like.

When refactoring, it is of great importance we are able to understand our code and identify such violations.

It is also important to examine where in our codebase do we have similar things happening, and when analysing a particular functionality, to make sure no file or function was ignored, that belonged to this category, so it is not forgotten when the certain category is being addressed.

Conclusion

Once Marie’s customers finish with the tidying up (apparently it takes some months), they are happy humans again, free from the cluttered homes and surrounded with only the things they care about.

Similar to that, having finished with the code refactoring might change our mindsets on how we write code, how we communicate with stakeholders, with our team members and how we feel about working on a particular project.

InnoGames is hiring! Check out open positions and join our awesome international team in Hamburg at the certified Great Place to Work®.