People love to talk about technical debt. They love to tell each other to “work smarter, not harder” and not to double your work by speeding up development today knowing you’ll have to change it later. The thing is that people call this debt, but it isn’t. You have made the best decision that you could at the time. In development, you have to make compromises along the way. When you decide to do a feature in a particular way, and you’re going to have to change it later, yes it is more work. But, it’s also done for now. The feature is out the door right now. Instead of considering it debt, consider it an opportunity for improvement in the software.
Mike Swieton from Atomic Object
[…]I’d say that technical debt is “the accumulated inertia from conscious trade-offs.” […] I use the term “trade-off” very intentionally here: I am purposely not saying “shortcut.” In my experience, […] trade-offs that make thing A simple and thing B more difficult are quite common and not always avoidable. […] The developer who came before us isn’t a bad person for leaving some tech debt behind. He or she didn’t make a mistake. It was almost certainly a calculated, careful decision made with incomplete information (and the information is always incomplete.) In all likelihood, the original author carefully considered the trade-offs and decided to emphasize one of the items from the list above over the others. And today, the factors that he or she considered have changed.
Technology is ever changing, ever improving, and ever evolving. Just because you don’t complete something the “new way” that was just come up with, doesn’t mean that you have technical debt. You make the best decision with the information that is in front of you. When you know better, you do better. This is why the opportunity for improvement in your software never ends. You can wait on an update that may be done in 6 months, that you’ve been waiting on for 2 years, or you can go ahead without it and then backtrack in 6 months or so to update it again. At least you’ve had it done for 6 months. There is always a compromise.
It doesn’t make any sense to shame ourselves and our teams for knowing better today. It’s about the priorities of the project, the quality of what you’re putting out, and the ability to improve and build on what you have in the future when you can. Work is work. These are not shortcuts – you are choosing priorities. Then, when you need to, you can use those instances to improve your software. Technical debt doesn’t have to be a negative. It can be a sign of real quality work. Thorough work where you are continually improving on the features and updates that you’ve had to put together in the moment.
What is your take on “technical debt”? How do you think it’s viewed? How should people consider it? What’s your opinion? Comment below!
