As indie developers we have to wear all the hats. Brainstroming ideas, design, code, marketing, user support etc… it can be overwhelming at times and more often than not, some tasks fall down the drain even though they are super important.

For me, refactoring code is often one of these items that get overlooked. Ever since I started buidling apps, I’ve always been excited by the ability to take ideas and turn them into cool products. Coding is just a means to an end and I’ve never found pleasure in writting “pure” code that would make a senior engineer at Google proud.

That said refactoring is important and today I wanted to touch on this topic in the context of indie development.

What is code refactoring anyway?

Hello Wikipedia… what is refactoring please?

Code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior. Refactoring is intended to improve nonfunctional attributes of the software. Advantages include improved code readability and reduced complexity; these can improve source-code maintainability and create a more expressive internal architecture or object model to improve extensibility. - Source: Wikipedia

In English, it basically means rewriting part of your code because it was messy, duplicated, too complex, hard to read, written using outdated or unnecessary complex APIs, too long… you get the point.

Why is refactoring so important?

Refactoring code reguarly is critical to avoid situations where your code gets to a point where it becomes difficult to update or maintain. This is even more importnat when you work within a team of developers that share the same code base and have different programming styles.

By refactoring code, you make your overall code base more efficient and more maintainable. In some companies, it’s a mandatory practice and all developers align on many things like coding style, authorized programming languages, dependencies and more. This ensure everybody works in harmony.

General best practice: when to refactor code?

Industry experts say that refactoring should be part of your workflow and should be given the same level of priorty as any other business critical tasks (i.e. developing new features, revamping your UI, marketing your product etc). I don’t necessarily agree with this but let’s dive in.

One of the best times to refactor your code is often before starting to work on a new udpate. At that stage, you can easily plan what you will add to your app or website, see which parts will be impacted and how that section of your program will need to evolve. Doing so should help you analyze the areas of your code that could be improved to make your life easier while you implement the next features.

Examples of questions you should ask yourself:

Do you see duplicated methods?

Do you have functions that do almost the same thing with slight differences in the parameters or return types?

Could the new features leverage existing code if it was written in a slightly more generic way?

Another great moment to refactor code is right after shipping an update. Your users are happy discovering the new things you just sent their way and that gives you an opportunity to take some time for yourelf (i.e. for your product’s health). If you’re like me, it’s often hard to dive back in the code you just spent so much time writting. And your natural reaction after all these efforts would be to just forget about it and celebrate the launch. But in reality, putting the next few features on hold for a few days and switching to refactoring more will help bring your overall product to a more robust state.

When to not refactor code?

In some situations, it’s not recommended to refactor code.

Premature refactoring is generally a waste of time, and possibly a risk for your business. If you just launched your product, it’s ok to have slighly lower code quality because you focus on growing an MVP (Minimal Viable Product) to bring it to the next level. At this stage what really matters is to make people happy with the features they asked for. More often than not, execution speed will be the key to your success (or failure) and this is definitely not in these early stages of development that you should worry about refactoring code. Just power through, ship as fast as you can and fix the mess later once you know your product has gotten some traction. If it never gets traction, having written amazingly nice code won’t make a difference anyway.

Refactoring for the sake of it is also a bad idea. If your product is stable and you are not planning to add new features to it. Don’t touch it. You would only risk breaking things for not potential gains. Worst, if you really mess up, you could end up with a bunch of unhappy users complaining about bugs. And there you’d be losing big time, bogged down in user support.

If you miss coding because you only have one product and this product is stable. Build something else, even if it’s for fun.

What are the risks of not refactoring code?

Not refactoring code can lead to painful situations where you start working on a new feature that relies on older parts of your code that aren’t ready to receive new integrations. As a result, you end up hitting a wall… a very big one… with a maze half-way through the top. I’ve been in that maze for the last few days and trust me, it’s not fun.

When you find yourself in situations like these… there aren’t that many options. Just brace yourself and power through the storm. That might last for a couple days but you’ll be thankful once you’ll be through with it.

Another risk of not refactoring code is to get discouraged and not ship features that could have been beneficial to your product and your users.

“I’d love to build this, and my users would love it… oh yeah but I have to clean this 1,500 lines-long file first. I’ll do this next time.” (Spoiler: next time often turns into never here, trust me I’ve been there too)

Refactoring code as an indie developer

As an indie, I work alone on my apps. That means I’m the only one touching the code base. It makes a huge difference compared to developers who work as a team. For them, refactoring is critical to ensure their code stays consistent no matter who contributes to it. I do not have this consistency issue but that doesn’t make things simpler for me nonetheless. Working alone also means that I cannot leverage other developers to help me improve the factoring of my code. I have one brain and I have to work with what I’ve got.

Additionally, when I don’t spent time working on user-facing features, nobody else is and that’s not good for my business.

That tends to lead to bigger interval between refactoring sessions. It requires discipline and 9 months after jumping into the the indiedev lifestyle, I’m yet to build this into my workflow consistantly. So far I’ve been refactoring code only when I had no other choice and it’s always been painful. I hope this will change in the future.

Wrapping up

As hard as I can be, try to see refactoring as an investment for the future of your products. But don’t do it too early. Your code will never be perfect… and we all know that shipped is better than perfect, so keep shipping!

If you want to learn more about refactoring, this book often gets recommended to me by other developers: Refactoring: Improving the Design of Existing Code by Martin Fowler.

If you’ve enjoyed this article, try to think of one person that could benefit from reading it and share it with him or her.

If you have any questions about this article and/or if you want to get in touch, you can find me on Instagram here or on Twitter here.

Til next time, code on!