Modern video games, especially the open world games all shar similar mechanics around the game’s scenario. The player has a main quest to achieve in order to finish the game, but in parallel one can explore a lot of diverse side quests that often impact the main quest one way or another.

I have found that this is not dissimilar to the development and maintenance of a software/product. Just like video games, most softwares have a clear purpose formularized around allowing the user of the software to achieve its goals. This goal is then translated to a set of features (The nomenclature can change from software to another) that need to be implemented iteratively. These features constitutes what is often referred to as a roadmap of the software/project. Let’s call this roadmap the “main quest“.

As the software grows, we, engineers and developers working on the main quest, face all kind of challenges along the way: sometimes just small annoyances with the code base, with the code style, with the development environment, with how the code itself is structured, a lot of inconsistencies can arise as multiple people collaborate on the same code with different approaches and styles. As the software grows, ensuring a bug-free experience becomes challenging as well, testing the changes become harder and slower, shipping features become riskier. In other words, the more we advance in our main quest, the more these struggles tend to accumulate, especially if left unattended.

So, we, developers need to make room to explore and address these side quests, sometimes referred to as technical debt as well, or we risk harming our ability to iterate on the main one.

To be able to defeat a strong Final Fantasy boss, one has to improve the skills of the characters, buy new weapons and upgrade existing ones, and train your team first. Similarly, developers need to update their dependencies, ensure a fast and reliable development environment, have robust automated testing that they can trust, share guidelines and documentation and make it easily discoverable for new team members. Developers need to constantly reassess how new features impact their code base, ensure consistency and make sure the abstractions are used or adapted properly. Failing to do so impacts the feature work, either the quality of the software or the velocity of the teams, sometimes both.

But there’s a risk, a lot of gamers enjoy the side quests so much, that they tend to focus on them and forget about the main quest, I can’t count the number of hours and sleepless nights I spent procrastinating and playing blitzball in FFX instead of going to fight Sin and finishing the game. The same risk exists for developers, a lot of us tend to like their tools and processes so much, that they spend most of their time improving them, refactoring, update dependencies and they forget that the ultimate goal is to actually ship features and improvements for the user, not for themselves. Side quests need to stay side quests and not take over the main quest. A balance needs to find found.

Over time, I’ve developed a personal framework to be able to keep that balance:

• All developers should work on side quests.
• Split your time between your main and side quests. The balance can be different for short term or new projects. My recommendation would be that between 20 and 40 percent of the developers time should be spent on side quests for long term projects.
• As you work on the roadmap, note and document the side quests that you might want to tackle.
• Don’t ask permission to tackle side quests, just do it while maintaining the balance.
• Do not work solely on side quests forgetting what really matters. This is one of the reasons I found that having teams dedicated to side quests tend to not be the best idea. You have to feel the needs to be able to address them properly. It is better if the side quests are a shared responsibility of all the developers/engineers.
• Do not tackle multiple side quests at the same time.
• Some side quests are big and long projects on their own, the whole organization should only tackly one (or two maximum) of these in parallel. For example: Do not change your Data Library and switch to a new set of UI components at the same time. Do one big change iteratively and once done, tackle another.

That said, it’s important to learn how to pick these side quests. Side quests have nothing to do with the famous Google 20% rule. Here are a few guidelines and examples of side quests:

• Side quests should ideally be related to the feature work you’re assigned to do, or the project you’re working on.
• Prefer production code side quests over tools but don’t neglect these either. As stated above, we, developers enjoy working for ourselves, tools to make our lives easier. These represent good side quests to tackle but production code side quests are often more important. For instance, picking the shiniest testing framework is less important than improving the loading performance of a page.

Examples of great side quests include:

• Improving and tracking performance of crucial UIs or flows.
• Fixing bugs you encounter and that seem neglected.
• Reconsidering your broken abstractions and hacks that you previously had to deal with.
• Consolidate multiple but similar functions, components, packages.
• Removing dead-code or features that are not relevant anymore (low usage).
• Improving developer or user documentation gaps.
• Automating a painful process.
• Deleting old tests that didn’t prove their worth.
• Exploring a small quick win that you think might have a great impact on the success of your project.

Ultimately, side quests are about caring for the quality and the long term success of your projects. Please care, but don’t lose sight of the ultimate goal (users).