If you've been on Netflix, the internet, or talked to anyone recently, chances are you've heard of Marie Kondo or "that one tidying show", aka Tidying Up with Marie Kondo. Marie's method (KonMari) focuses on sparking joy during the tidying process. As best said on her website here

"The KonMari Method™ encourages tidying by category – not by location – beginning with clothes, then moving on to books, papers, komono (miscellaneous items), and, finally, sentimental items. Keep only those things that speak to the heart, and discard items that no longer spark joy. Thank them for their service – then let them go."

Software's architecture is often compared to the structure of a home -- the foundation and building blocks to what will become a house. So doesn't it make sense to compare our code to the clutter in our home? Some homes have more, less, but there's almost always room for improvement. Marie Kondo focuses on creating an organized home that sparks joy. Let's do it! What can we apply from the tidying expert to get our code in better shape and spark joy?

First step: Identify Joy. To some it may be the feeling of holding a puppy, but for technologists, it may be the feeling of opening a file and being able to easily navigate it. Determine what makes you happy when going through code, and aim to get that feeling in your own codebase.

Note: Take an agile approach and make this process work for your team/workflow.

As KonMari does, let's start breaking things down by category.

Challenge: Open your project, and organize things by category. For most codebases, I imagine this would be feature driven, but use what works best for your team.

For every category in the KonMari Method, Marie asks homeowners to collect their items that fit in that category, place them in the middle of the room and then hold each item individually. Items that spark joy, put in a "keep pile" and items that do not, put in a "discard pile".

Challenge: We can't go around killing off ugly code, but lets identify one thing (method, file, etc) that really bothers you or your team about the codebase, and start with that.

The idea with this challenge is not to go rouge and start rewriting your entire application, but instead find areas to improve on over time. Start with what bothers you the most, focus on it, and move on to the next item when you're ready.

Break out big functions into smaller scoped methods.

Update variable and function names to be more informative.

Make small, frequent changes and commits that are easier to track.

Streamline similar or duplicated code.

To take this steps further, I recommend checking out out practices in Clean Code and Read by Refactoring.

After applying some of these basics to repos I've been working in, I started seeing other areas ready for improvement. Cleaner code revealed that logic not previously tested was not much easier to write tests for.

Challenge: Look at what you've refactored, make sure appropriate unit / UI tests are there, add any that are missing, and remove any unnecessary or redundant tests. A good rule of thumb is to aim that logic is being tested first. Any if statement, data mutations, etc.

The last big area I found improvement in was removing unnecessary views. When you have a lot of contributors, things get messy over time. It's just a fact of development. Using a view debugger, something that allows you to see the layers of your application, can be very eye opening into what is redundant or never being used.

Challenge: Identify super views that have one subview, making the superview irrelevant. Identify views that are hidden and never shown. Identify views that are never added, etc. Cleaning up these views will help with the performance and maintenance of your application.

Again, feel free to modify this to fit your workflow and team's style. Do not take on an application re-write, but instead try to incorporate one small thing into what you're currently working on. Small improvements add up over time. I've been very happy with the results of applying this inspiration from Marie, Clean Code and Read by Refactoring and I think you will be too. If you try it out, be sure to circle back and share how it's going!

Happy Refactoring!