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.


Hello! How nice of you stopping by! ❤️

My name is Olof Thorén, I am an indie developer from Stockholm, Sweden.

I really enjoy creating stuff, and that is the reason why I am doing this. I started working full-time on building apps in 2009.

At the moment my main focus is Feeds, a glorified news and RSS-reader that keeps track of the web for you. I also build Qiozk Solo, white-label magazine apps for (mainly Swedish) publishers. I have published ~75 Solo-apps though most of them are not active today. Aggressive Development has published 15 apps under its own name and many more for other companies.

Please feel free to say hello on twitter @olof_t or email olof@aggressive.se. Don't hesitate to send me comments or feedback on anything I write.