Skip to content

Hammock thoughts

Refactor as you go

domain driven frontend, Architecting UI2 min read

As you can see, some time has passed since we started the refactor. Initially we received a month of refactor. This was due to a long and intense year, were finally our R&D manager insisted on a dedicated tech-debt month. We made many fundamental changes over the year and worked really fast, gaining a lot of tech-debt so it was time to pay up. This gave me the time to dig deep and think of the grand scheme of things. It freed up the mind to stop and look at the big picture.

The refactor month was declared a success, and the new year began and with it the stress of ongoing work and tasks. Initially we had a few related tasks so it was easy to continue and leverage these tasks and continue refactoring. Then came a few backend tasks, and some bugs... and quickly we got back to our old routine.

A few months later we a new task which enabled us to continue refactoring. I wanted to jump back straight to where we left off, but I had a lot of dust to remove... I had to explicitly remove myself from the ongoing work and step back. Returning to the code wasn't that hard, the difficult part was to put myself back in the refactoring state of mind.

I think a lot about the different state of minds that we need to juggle - code, test, plan, research, etc... Each of these requires a different view point, and you need to take a step back from the problem at look at it again from a different perspective. For the first time I realized the architecture might be another one of those.

So, what is this rant about you ask? I'm starting to think how do we create space for this type of thinking in out day-to-day? One idea I would like to try out is BaseCamp's Shape-Up strategy, or generally the way they approach the classic "sprints". Each cycle (what we refer to as sprints) is 6 weeks long, and then they have 2 weeks in between each cycle. On the one hand I think this creates a lot of space to breath and is healthy in general. But more to the point, this is the point in time where we can lift our heads for a moment, take a deep breath and review how the new feature fits into the bigger picture. Are we happy with the way it turned out? Are there any quirks we would like to fix before entering another cycle? Essentially this is a clean-up phase, but it forces us to shift gears and look at things from a new perspective.

I'm still trying to think how do we do this in the classic Scrum / Sprints model, but what I do know is that we have to keep putting on the architect's hat and return to this point of view frequently.

© 2022 by Hammock thoughts. All rights reserved.
Theme by LekoArts