How can I have a debt if I didn't borrow any money ?
This is the first question that technical debt brings to mind.
But let's approach technical dept with an example: Bob had to paint his flat, he spent all Saturday doing it. He was invited to a really cool party on the evening. By nightfall, Bob had just finished painting but still needed to clean the brushes and put things away. He said "you know what ? f*** it", stuffed roughly all the paint pots and brushes in the closet and went to that party.
What do you think about Bob's attitude ? Is he a pragmatic man ? Or a low-life and immature person ?
There are 2 key things to understand in this story:
Bob could not have been to that party if he had to clean and put tools away after painting
Bob ca no longer use his closet normally because his clothes are blocked by paint pots
Understanding Bob's story is understanding technical debt - there is nothing more to it. The next paragraphs are about helping you choose when to clean you brushes and when to go to the party.
Doing the right thing: a practical example
Let's take a technical example: You have a component that needs to fetch data from an API. As a good developer, you know that the right thing to do is to create a service/store/hook/function (or whatever your framework calls it) to put all the API logic and inject it in your component.
However, software development is about delivering things that work. And the fastest way to do it is to skip the service thing and make that HTTP call directly from your component.
Is it bad code ? Yes. Does it work ? Yes.
There are obvious reasons why you should not do that: poor readability, it's hard to maintain, there is no separation of concerns and this will inevitably lead to WET code if that call is repeated elsewhere.
However.
If that code will never be touched again in the future (not likely) or, if you do not care about how this code will be changed in the future (more likely), bad code can be your best option. End of chapter 1.
Time capsule: doing it again
Let's imagine that the you from the future opens that stinky codebase from chapter 1. You have to create a new component that calls the same API. See where we are going ?
Once again we have two choices:
Clear that technical debt once for all and to that damn service, and implement it in both components
increase the technical debt by ruthlessly copy-pasting your code in the new component
Does the trade-off change ? No. It is exactly the same situation as above, you have to choose based on the situation. Be quick or be solid.
The outcome: mastering technical debt
From a developers' perspective, it is clear: bad code is bad code, it is evil. Every book and tutorial will tell you exactly that you should never write bad code.
Yet, from a different perspective, the reality is not that simple. Bad code is never 100% bad and neither is good code 100% good. There are also deadlines to respect, profitability to ensure, new contributors to integrate among many other factors.
Does it mean that you have to make concessions and give up on good practices ? Not at all ! Bad code will definitely come back at you soon or late and you will pay it slowing development, weakening your app and annoy developers because no one likes to work on a stinky codebase.
The point is finding the sweet spot: nothing is absolute, everything varies from situations. Sometimes you have to deliver quickly, sometimes you need to consolidate.
It is when you start evaluating and embracing the technical debt, knowing what you get in exchange for it that you pass from developer to CTO.
Ship fast without trading off your standards with Manifest
If you understand that mastering technical debt is key, you will love Manifest ! It is an open source 1-file backend that allows you to create complete backends quickly while keeping your coding conventions and standards.
Star the Manifest project if you want to see Manifest grow ❤️.