Why Technical Debt is not Bad Debt

#technicaldebt #startup #refactor #javascript

Release early, release often - just don't forget to refactor ;)

Deliver Now

As software engineers, our main objective is to deliver. Once our code works as expected, we commit it and then run it in the CI/CD pipeline.

While seemingly straightforward, it’s not as simple as it may seem. There exists a constant tension in the programming world that stems from shipping fast or slow at the cost of software maintainability aka technical debt.

Technical debt is opting for the easy solution now instead of using a better approach that would take longer. More often than not, many agile teams choose the former than the later.

Deliver now and fix it later is a very popular approach because teams are able to reduce the time it takes to get product-to-market. It’s also great because software engineers don’t have to spend too much time developing something that might be used. For many companies, it’s a fair trade off. Nevertheless, in order to make this approach work, continuous refactoring must be done — else technical debt will accumulate.

techdebt — The bigger the technical debt, the harder it is to add features.

Fix it Later

“Fixing it later” is synonymous with code refactoring.

Code refactoring is the process of clarifying and simplifying the design of existing code, without changing its behavior.

From the business and end user perspective, this doesn’t affect them because the product doesn’t change. However, from the developers’ perspective, refactoring reduces technical debt and increases software stability.

This makes a huge difference in larger projects.

Code is Read More Often than it is Written

There are a variety of scenarios when one should refactor.

The following is a general list of things to look for when identifying code that could use some refactoring:

Copy & paste (duplicate) code
Ambiguous variable names
Unused variables / methods / classes
Suboptimal performance
Your method’s code is longer than your screen
Violation of DRY, KISS, YAGNI, SOLID and other software engineering principles

Feel free to suggest any other scenarios in the comments.

Example of Refactoring

In this section, I will show a simple example of javascript code pre and post refactoring.

Pre Refactoring

Post Refactoring

Code Review

Results: both example produces the same outcome, which is to unset the users rank.
Visually: Pre-refactoring has a lot more code than post-refactoring.
Performance: Pre-refactoring makes up to 10000 roundtrips to the database, while post-refactoring makes 1 roundtrip to the database.

Imagine if more developers joined this project and stumbled upon this code. Do you think it would be easier for them to understand and contribute to pre or post refactoring?

Conclusion

Just as the author would improve their writing to make it easier for the readers to understand, developers should also improve their code to make it easier for other developers to understand.

My advice to those in a team where you’re constantly cranking out new features, consider setting aside a sprint or two for stability. Write some unit tests to increase your code coverage and refactor some code to make your apps more robust. I know it might seem like it’ll slow down development time, but it’ll actually increase your team’s efficiency and output in the long run.

Thanks for reading! Originally posted on Santora Nakama.

Top comments (4)

Jean-Michel 🕵🏻‍♂️ Fayard • Oct 3 '19

Nice article.

I would put more emphasis on why you shouldn't be afraid to be messy before you refactor.

In fact I wrote about it here

with(ConfigObject) { "Language $KOTLIN".isSparkingJoy() }

Jean-Michel Fayard ・ Sep 15 ・ 3 min read

#kotlin

That shitty first draft

When I'm starting to work on a project or a feature, my initial code is messy.

It has thing that are hard-coded but shouldn't. It has top-level properties and functions all over the place. Sometimes implemented twice. Things that should be extracted but are not. Things that are extracted in a way that doesn't really make sense. Usually with a bad name.

That initial messy code serves important purposes. Playing with and learning a new API. Validating that it makes sense to invest time into an idea. More importantly, it's a remedy against perfectionism. On this, I am with writer Anne Lamott

Perfectionism is the voice of the oppressor, the enemy of the people. It will keep you cramped and insane your whole life, and it is the main obstacle between you and a shitty first draft.
Perfectionism is a mean, frozen form of idealism, while messes are the artist’s true friend. What people somehow (inadvertently, I’m sure) forgot to mention when we were children was that we need to make messes in order to find out who we are and why we are here — and, by extension, what we’re supposed to be writing.