Technical debt is okay, sometimes
What exactly is technical debt?
“Technical debt is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.” Wikipedia
One of the roles of a software developer is to minimise technical debt.
But when you’re a maker and you’re trying to rapidly prototype over ideas to see what sticks, it doesn’t make sense to spend this extra time trying to perfect everything after all for you especially time is money.
You should take on technical debt. Take it on now because the chances are a lot of products won’t make it, fix the technical debt in the ones that do.
If you follow this rule you’ll save yourself a lot of time, which means you can get out more products or revisions to a product and see what sticks faster, once you have the thing that sticks you optimise and remove your technical debt.
The important thing here is that i’m not advocating avoiding your debts. You must pay off your technical debt by making time to redesign and refactor the areas that need it.
I’m also not advocating taking technical debt as a strategy after you find product market fit and aren’t “drowning” from lack of funds. If you have product market fit and some cash coming through the door, you are in a position to avoid the debt entirely.
Which is why technical debt is okay, sometimes.
