Fetching articles...

Spring cleaning the technical debt

These last ~9 months have been a race through the underbelly of technical debt. I have at the same time delivered a lot of apps, been trying to get a new company of the ground (and failing, more on that in another, more sad post), and learnt how to do everything myself. It was not that difficult to do it all myself, we only were two people before so there were just a few task where I wasn't "the main guy". Technical debt is a rather tricky thing, when do you decide to deal with it? Things work as it is, and if you are just going to some cleaning, it will not produce new sellable products.

The tipping point for me was that I just couldn't handle all the bad code myself, I knew there wouldn't be enough time to deal with it if I ever wanted to make a change. For our QiozkSolo-web apps every web page was generated from a unique script. Nothing was reused even if it was exactly the same in every single page. E.g. the header, which contains the shortcut icon usually seen in web browser's URLs or tabs, was just copy-pasted to each and every location. So if I ever wanted to make changes, there were 25 different places I needed to tweak (and test). This type of code-reuse by copy/paste was all too common in the project and had to be dealt with. Making changes was simply impossible. Now, every web app has their own icon, a oneliner fix that took about 5 seconds to write and test.

When trying something new that you probably will throw away, copying an older project and just trying some new things out, is a really fast way to go. But then you must take the time and refactor the code if you want to keep it. When you are already working 60 hours a week, it's hard to squeeze in another day to review and refactor code, with no additional benefit to the end user.

Refactoring is also not very rewarding. You do a lot of work, and the result is exactly the same (if you didn't screw up). It is however, the smartest way to design an application (in my opinion). You can either try to imagine every single possibility and use-case that you will ever deal with, or you can build something that works and re-design afterwards. When adding a new feature, I also like to start with refactoring (if at all necessary), since then you have enough knowledge to know how the new pieces will fit and can adjust the code accordingly. Just because the code is written does not mean it is set in stone. Naturally, this is not always true, if you build a library, framework, or an API, you need to live with your decisions forever.

Anyway, just wanted to tell you this so the work has not been for nothing. It feels so incredible great to have everything consolidated into one body of code, which I can have complete track of, and if I update something I know that everywhere this functionality is used, in all of my 30+ apps, that piece of code gets updated.