Just recently I’ve reached 1 year of working on the same project at the agency I work for. This is pretty unheard of. Agencies are usually the ones that work on short-lived projects. It’s in and out as quickly as we can manage then on to the next one. Usually. This project was slightly different. This project was an initial build of about 3-4 months, followed by a global roll-out across the space of the following year. We currently have 11 out of 30 sites launched, with the remaining 19 in development with the aim of them being live before the end of the year.
While I’ve had a few short breaks from working on the project to do a couple of little projects here and there, I’ve been pretty much working on the same code for a year. However, because of the nature of the project I’ve also been working with a platform that was pretty much set in place in the first 4-5 months. With it being expanded to include a few modifications for the extra sites and features.
This can put you in a very awkward position when it comes to this industry. We move so quickly and can change our entire way of working from month-to-month. I don’t think in my time as a developer I’ve written many projects in the exact same way. Every time I’ve either tried something new, or learned a better way of achieving the results I’m after. However with this project, it’s forced me to concentrate on the same code, with ideas and structures decided upon within the first few months of the project. In particular, this project became one of the first larger site architectures that I’ve worked on myself and built from the ground up. So that initial few months was me mostly finding my feet, adapting to writing a lot more complex code for a large evolving website with a variety of needs. Fast-forward 8 months after the first of the eleven sites were released and today I’m working on modifying the same files I authored at the very beginning of the project. While some areas have been refactored, these are in the minority; the initial code structure very much still remains.
Old code sucks!
Working with old code sucks. In this industry when we’re constantly evolving our practices so regularly and with the environment changing around us every day, you look back on code you wrote a few months ago and wonder what on Earth you were thinking. Now think about code that’s 8 months old and you can start to imagine how I’m feeling right now. The code I wrote 8 months ago is starting to show it’s age; with the constant additions of new features and new websites, it’s seams are becoming weak and the cracks are beginning to show.
It’s getting frustrating looking at this old code each day and having to code around it to get things done. To ignore the mess that exists and just add new things in order to launch a new feature or new website on the platform. But this is sadly a necessity at this stage as time isn’t allowing us to work on things the way I would prefer. And I guess that’s always going to be the case with some projects in some situations.
Refactoring
I mentioned that some parts of the project have been refactored. In small areas there have been improvements, however few and far between. The issue I think I’ve faced with refactoring is wanting to do it all at once, trying to make these grand plans for how to restructure the entire Sass or to normalise a lot of the templates into fewer, more reusable functions and partials. There’s a problem with this approach however that when you have a lot of people working on the project at the same time and one person is off refactoring a lot of the more general code, by the time it comes to merging those changes back together you’re going to end up with lots of conflicts and a high probability of something breaking.
About a month ago I went to Sass Conf where Elyse Holladay and Jina Bolton did a workshop on refactoring. At the time I was working on a fairly major refactor, trying to restructure the Sass partials for the project and normalise a lot of the styles. During the workshop I decided to merge my refactoring branch back with the main develop branch of the project, only to spend the rest of the workshop fixing merge conflicts instead of refactoring. A lot of what Jina and Elyse taught during the workshop was valuable methods to refactoring your code. However there was one main thing I took away from what they were saying – reinforced doubly so while I fixed all those merge conflicts – that refactoring should be done often and in small chunks.
The refactoring I was attempting to do would restructure a vast amount of the Sass on the project and change a lot of the way things were styled. Due to this, despite the amount of testing we did before the changes went live, a bug still appeared on the live sites caused by the refactoring. It was caught pretty swiftly but still, it made us look bad to our client, and me look bad to the team. All down to me trying to refactor far too much in one go.
Don’t wait, refactor as you go
Since this happened I’ve taken a much more methodical approach to refactoring this project. Instead of waiting to be given time to do the refactor, or doing a whole lot of work in my spare time, I’m baking refactoring in to the work I do. If there’s a new feature, I’ll look at what things it my affect and refactor those to work alongside the new feature. It may take a little extra time to get a new feature built, but in the long run this will be invaluable to the project.
This past week I’ve also been given a bit of time to work on some specific refactoring bits for the project. But instead of making one big refactor branch and letting it get out of date with the work still going on, I’m working on it piece by piece. Refactoring little bits of code and merging them back in and pushing it live as soon as possible. It really helps to prevent errors because you’re focusing on usually one small part of the code so can more easily work out what parts of the site it will affect. And any conflicts caused by the refactor can be resolved pretty easily too.
Final thoughts
It’s pretty easy to feel bogged down when you’re working with old code. The pace of change in our industry means that we’re constantly changing how we write our code or what techniques and tools we use. Even code that’s a few months old can look poor to our ever changing standards.
To keep your motivation going and feel proud of your work again, you will probably look at refactoring things. To bring your code more up to date, or to fix problems you didn’t foresee when starting out. The urge can be to refactor everything at once, and try to make major changes. But we need to remember to be more cautious. Refactor while we build a project instead of when we’ve finished and remember that refactoring small sections at a time is going be a lot easier to test and prevent errors.
In the past few months I’ve been feeling extremely demotivated looking at and working with old code. Not being allowed the time to refactor it when I would like to and when doing so causing errors and bugs where I shouldn’t. Recently however it’s more apparent that I need to take refactoring into my own hands. To do more while I’m working on new features or to take on smaller amounts of refactoring instead of trying to do large chunks at a time.