If you’ve ever worked for a startup, then you are probably aware of the term known as technical debt. Essentially, it’s the amount of work that you and your team will inevitably have to do in the future, due to choosing a quicker and less scalable solution today. This is mainly done for the sake of time with the awareness that the solution isn’t final.
And depending on the amount of it at your company, it can get pretty expensive. Development time tends to be on the higher end usually when it comes to startup costs, so making effective use of a programmers time is crucial in order to get any form of progress.
But, and I might be unpopular for saying so, technical debt is also highly beneficial in order for a company to iterate faster. Having functional code to run and to demo paints a much better picture about your current progress to you and your team. The faster you can get your code into any users hand, the faster the inevitable design flaws can be found and fixed.
But it’s not just about speed and quick deployments. Taking on technical debt, can also benefit other areas of your development workflow.
Proof of concept
Working for a startup is vastly more different than working for an established tech organization. A mature tech company has already done the work in order to become financially viable (usually). Meaning that those codebases have been refactored and reworked many times over. A startup is in the process of doing that work.
And that means errors, bugs, dead ends and sometimes even designing things on paper that aren’t yet possible. But the only way to really know that, is to start building it right now.
This is the most common form of technical debt that you will find in a company and it’s occurring on a daily basis as developers meet with business teams and project managers and troubleshoot logic errors.
This is good technical debt in my opinion, because knowing that what you are building is viable, is much more important than simply just building anything for the sake of building it.