“Technical debt” is making a programming choice based on getting something to work in the short-term, even though you know it will have problems in the long-term.
Think of technical debt as credit card debt, where you only make the minimum payment and keep charging new things on the card. Eventually, you’ll reach your credit limit and not be able to charge anything new.
In programming, this is when your program has become so unmanageable that any change break another part of the program, making it take longer and longer to make each change. This may lead to declaring “bankruptcy” with the program – writing a completely new program, instead of continuing to work on the existing program.
Technical debt is related to YAGNI and and preparing your code for problems. There needs to be a balance between short-term decisions and long-term decisions. Unfortunately, making the best choice for this balance is usually something that comes with experience.
When starting your programming career, if you aren’t sure whether to take a shortcut or make something more robust, check with a senior developer on your team, your manager, or the product owner. Let them know you can do a short-term fix that will take <X> amount of time/effort, but potentially cause a problem in the future. Or, you can make the long-term change that will take you <Y> amount of time/effort. Then let them decide.
I will warn you, people will decide to take the short-term choice, but expect the long-term results. Or, if/when the short-term choice becomes a problem in the future, they will suddenly forget they were the one who chose it. That’s part of human nature.
It’s also difficult to get the business people to allow you time to fix this technical debt. As far as they’re concerned, the program works, so you shouldn’t waste your time making changes to it.
Return to “Life as a programmer outside Silicon Valley” index
So far, I have learned so much that I can try implementing in my working environment, thanks a ton Scott