It happens on the best projects and to the best teams. Eventually every code base accumulates some form of technical debt. It can come from consciously prioritizing short term output over long term maintainability, from less conscious neglect or simply from outgrowing an original architecture design. Despite its mostly negative connotation taking on technical debt can sometimes be a sensible idea if it allows you to ship an important release earlier and make your users happier.

Regardless of whether you accumulated your technical debt deliberately or recklessly, the debt must eventually be repaid or your team’s productivity will start to spiral down out of control. The internet is full of good advice on how to fight technical debt by writing refactoring tickets, doing code reviews, etc… There’s even a lot of advice on how to sell it to your non-technical manager. The trouble with lots of these approaches is that they rely on the same process that made the technical debt appear in the first place. The chances are that the same pressures that made the it appear can thwart your attempts of repaying it.

Here I’d like to introduce a different way we recently tried out at Liefery and it’s a slightly more playful one.

Tessi proudly wearing the rainbow hat

We bought some hats…

We now have 2 special hats that are passed around the team and I don’t mean figurative hats, but actual real literal hats. Silly hats to be exact.

We currently have the “performance shark” hat and the “rainbow” hat and they work like this:

Whoever gets the “performance shark” hat gets half a day of our one week iteration to make some part of our platform work faster.

Whoever gets the “rainbow” hat gets half a day of the iteration to “make the project a better place”. The definition is purposely vague and it could mean making a part of our codebase nicer to work on, improving our tooling, automating day to day tasks, contributing a change to a dependency we use, trying out an interesting feature that’s not on the backlog, etc., as long as it benefits the team or the product.

Tobi and Edward combining the power of both hats

The important part of owning a hat is that the hat-time that comes with it is self-directed. There is no prioritized ToDo list for a hat wearer. There only has to be a positive outcome for the rest of the team at the end of the hat-time. Self-direction brings with it additional motivation and provides a welcome change from the normal feature-driven or business-driven development tasks and makes owning a hat a privilege rather than a chore. It balances the often short term interests of the business (“I want this feature in production yesterday”) with the typically more long term interests of the development team (“I want this codebase to be fun to work on”).

Our iteration meetings are now way more professional

In every iteration meeting the team decides who should get the hats for the next iteration. We typically balance this so that everyone gets an equal share of hat-time, but they can also be given out for special achievements like finishing a big story, solving a difficult problem or to compensate for taking on an undesirable task.

Manuel making the world a better place

And obviously, while working on hat-time… one has to wear the hat.

Shark time!

If your team also finds it difficult to fight technical debt I’d encourage you to try this out too. It’s a very fun and playful way to improve the quality of your code and balance your team’s short-term and long-term interests. And if you do… I’d love to see your hat-pictures. Send them to me by email and I will publish them in a gallery if I get enough.