In the Tax Engineering team at FreeAgent we’re currently working on adding Corporation Tax and Final Accounts filing to our application as we continue our mission to help our customers relax about tax. We’ve been working on these features since June and recently released the Final Accounts report and the CT600 form, but what you might not know is that work on this project originally began back in 2017. So what’s the reason it took us so long to release anything? Three words: Making Tax Digital.
Making Tax Digital (MTD) was first announced by the government in 2015 and its aim is to “make it easier for individuals and businesses to get their tax right and keep on top of their affairs”. It was originally planned to be introduced in 2018 but was eventually delayed until April 2019.
What this meant for the Tax Engineering team was that work we had started on Final Accounts and Corporation Tax filing had to be halted as we shifted our focus to work on supporting VAT filing via MTD. Once that work was completed, several changes within the Tax Engineering team and other annual updates to established features meant that we weren’t able to pick the work up again until June 2020.
By that time the code we were working with was over 2 years old and a lot can change in that time, not least the team itself. None of the software engineers who originally worked on the project were still with the team.
What is Dormant Code?
Dormant code is code which is in the codebase but is not being actively used. In our case, some functionality had been built and was in the codebase, but it was hidden behind a feature flag. In addition to that we also had a work-in-progress pull request (PR) from the same time which was never merged into the main app.
How Did We Start?
1. Talked to the people who wrote it originally
We were fortunate that one member of the previous team who worked on the project originally was still with the company (albeit as part of another team now) and talking to them as a first step was hugely beneficial. They could talk through the decisions that were made at the time and highlight any areas which may need improvement.
2. Got it running
Once we felt we had a general idea of what the code was trying to do, the next step was to actually get it running. We ran any tests already in place and updated them if necessary to get them passing. Next, we fired up the app, checked the functionality was working and did what was originally intended, making any necessary changes along the way.
3. Got it up to date
Programming languages and frameworks are constantly evolving. What was the latest and greatest technique even 1 year ago might be seen as out-of-date now. For example, we had some custom code which rendered a view outside of a controller. We were on Rails 4 at the time, but have since upgraded to Rails 6. A new feature was introduced in Rails 5 which enabled us to update the old code to use the new technique, making it much more clear and concise.
As well as language changes, there may have been changes in the domain you’re working in. Our Final Accounts work required us to integrate with Companies House APIs and their guidance on how to do that had changed too. We went through the dormant code with a fine-tooth comb and made sure that we were still meeting all of their requirements.
4. Built on top of it
Once we were happy that it was up to date and all the tests were passing, we could confidently build on top of it. This was the point at which we tried integrating the old PR, pulling out parts we wanted to keep and discarding other parts we felt were no longer relevant. We added additional tests for areas we felt needed them and started working through the to-do list we’d been compiling in steps 1 to 3!
Forgotten, But Not Gone
If there’s one thing we learned while working on this project it’s that dormant code doesn’t have to be dead code. If you can gain an understanding of what was originally done and be confident that it is still fit for purpose, then why reinvent the wheel? Why not instead just improve the wheel.