Spring Cleaning

By Malwine

Think of your desk at home or in your office. The desk you would put your computer on and work with. Is it empty or are there lots of things that made it there at some point and were never removed? Do you feel like cleaning it up or better postpone it?

The problem

Now think of your software project. Did it happen, that parts of your codebase got off your mind? Or worse, you knew about weak and obsolete parts but you never found time to reorganize and improve them? Contrary to non-developer opinion, after you ship code it is not gone for ever. The opposite is the case: the code keeps influencing all the work you do afterwards. Consequently this can lead to team frustration and stress in the long run. For example, your codebase can become hard to understand and maintain if it’s untested or non-DRY.

The start

At the end of 2014, we developers at DaWanda had our yearly team health retrospective. The outstanding issues with our codebase were the main factors for slow development cycles, as well as the general happiness of the development team. We requested to have a dedicated sprint for cleaning up the major things.

The first sprint of the year looked perfect for this kind of project as we had less stress with our daily routine. Our request was granted with the condition of having a list of tasks we wanted to tackle. Everybody could add topics that caused pain which were then prioritised by the core dev team.

The tasks

We knew from daily experience, and especially all through Christmas, where the biggest pain points and improvement opportunities were. Since 2013, we shifted from a fairly organically-grown codebase to a new, easy maintainable infrastructure and stack. But the legacy codebase keeps influencing us.

Here is a quick overview of what we did in the Clean-Up-Sprint:

• Big parts of the legacy app were migrated and refactored to the new stack. The objective was not only to copy over the code, but to reimplement, refactor and fully test it. Through this, we could avoid making the same mistakes and rethink our old software design.
• Some huge parts of the legacy app were removed either because they were no longer needed or they were re-implemented in the new stack. This was important because we wanted to have less old components to maintain.
• We also took this opportunity to refactor our new stack. Files that grew considerably in the previous months were split, following the principle of separation of concerns. All of these changes were made in small iterations and in a test driven way.
• A new gem was created to meet our requirements on HTTP resources.
• We discussed how to improve our Java-based caching solution and ended up changing its garbage collection strategy with the help of JVM monitoring tools to measure results. Then we improved the way our caching solution was purging stale data from Memcached. As a result, our users can interact with the DaWanda webpage significantly faster than before.
• Moreover, we discussed new external services, introduced them or upgraded old versions.
• We cleaned up our styleguide and removed duplications in order to prevent confusion in the future. We approached our goal to have all our components with their styles in this one place, as well as giving this app our corporate style.
• Finally, we tidied our Github repositories and removed obsolete ones. Furthermore, a big bunch of stale branches were thrown out. Open pull requests were reviewed and also reduced to only the most recent ones.

The methods

From the beginning, pair programming was intended and it was clear that it would become important. After some initial challenges, the team were focused on it. On average, every team member paired with 2 to 3 other team members in this sprint. Some pairs worked together for days, which can be exhausting, but also very productive.

Many people do not realize that most of the time we spend solving software problems is not only about finding a solution, but also about reading and understanding the code and the problem itself. The part of actually writing the code is only a fraction of that time. Therefore with two minds thinking of a solution, the problem can be solved faster, with less mistakes and higher quality.

Even team members working remotely paired successfully. One pair completely refactored a controller of our frontend app. Following the refactoring, they raised our CodeClimate rating from F to A, and there was full test coverage — an amazing result!

When team members were asked what they liked the best on the Clean-Up-Sprint, the majority mentioned the pair programming. Moreover, they mentioned the sharing of knowledge. It was a prime moment to ask other colleagues questions and they took the time to explain. We learnt a lot of new facts about our applications and gained new skills. We also rethought the software structure and certain implementations from the past to get an inspiration on what to do differently in the future.

We organized our sprint via JIRA (what we use also for our normal sprints), to keep roughly track of estimated effort, tasks completed, and the actual effort taken. Looking back, the feasibility of tasks should have been defined clearly to avoid tasks that cannot be fully completed within these two weeks, or tasks that leave room for improvement.

The outcome

After the two weeks of our Clean-Up-Sprint, we had done a lot to improve our codebase. Many overdue tasks were tackled. We facilitated work processes for our team and reduced many pain points for us and our users. Consequently, the happiness in our team increased and we were proud of our shared success. An almost hackathon feeling was created as a result of less meetings and more pair programming.

After the sprint, all team members said that they would recommend to do a Clean-Up-Sprint on a regular basis, and 64% said they reached their goals. The remaining percentage stated that they had reached them partly.

Next time we want to focus on optimising the organisational process and plan better. The Clean-Up-Sprint also showed us that we would like to integrate this kind of sprint into our working routine. Moreover, we got inspired to do more pair programming and to share our knowledge. Additionally, cleaning out old and nasty parts of the app has become more of a daily habit for everyone.

We can recommend to dedicatedly clean up from time to time!

Originally published at https://www.codeoclock.com/2015/03/03/clean-up/ on March 3