Sometimes it is hard to be able to do things that we know are nescessary in development. There could be multiple reasons for that. Productivitiy blockers are one of them. Another is plain old time. In this post, I will describe one of the ways we use to make sure that we consistently get some time to work on maintenance and tech debt.
As we are a large company, there is a lot going on all the time, and a constant pressure to deliver features that our customers and the business want. At the same time, we want to be able to spend time on doing experiments, fixing our infrastructure, removing tech debt, upgrade dependencies, and everything else that goes into maintaining code.
These two concerns can sometimes be hard to balance - but we know that it is important to prioritise code maintenance. On the surface level, it is easy to view it as an opportunity cost. Time spent on maintenance is time that is not spent on delivering customer value, and so should be minimised. And that may be true in the short term. Spending the time to, for example, switch out the JS transpiler, is something that will delay whatever feature I could be working on now. But in the long run, it saves us time every time we build our app. And it reduces the time we need to wait for our code to get into production.
Other examples that have easy to see benefits in a mid- to long-term perspective is to reduce code complexity, so that the code is easier to maintain later. Upgrading your dependencies continously, so you don't have to spend a month migrating to a new major version that you are far behind on - or even worse, continuing to use an old version with known security holes, because you cannot spend the time to upgrade.
In Telia, we want to work continously with maintaining our code. But sometimes the prioritisation is hard to get in day to day. So we created a mechanism to make sure that we have the time to improve and experiment. Once a month, we have a "Get Shit Done day" (or the more manager-friendly "Get Stuff Done day"), where all developers on the team spend the whole day working together on fixing something that we want to fix.
The rules are quite simple:
- There are no meetings allowed on the GSD day
- If possible, developers should find a place to work together the whole day
- You are allowed to turn off slack and other apps to remove distractions
We usually plan ahead of the day which tasks we want to tackle. We have for example spent a few GSD days migrating our app from Amazon ECS to Fargate, which has massively simplified our infrastructure. Another GSD day went to splitting up the frontend and backend build of our app, and caching the dependencies of the backend, which reduced build times of our app from ~1h to 10 minutes.
More recently, we spent a GSD day to figure out if we could render our new micro frontend app in our old apps. Which it turns out we can, quite easily! Another added benefit is that this contributes to dev happiness. We get to spend a whole, uninterrupted day to work on stuff we have wanted to do, and that makes our lives easier. And often the tasks we pick are tasks that we think is fun to work on.
The GSD days have given us at least one day per month where we can work on fixing stuff in our apps that is not features. Have you tested out something similar, or do you want to know more? You can reach us on twitter!