Everyone wants to produce good software, free from technical debt. Often the goal of producing good software conflicts with the economic reality of building software and compromises get made resulting in technical debt being taken on. Knowing whether you need to make a compromise on quality to achieve a goal, if you can achieve the goal with quality, or if the goal itself is flawed is difficult. You need to understand the goal and what you can actually accomplish in order to determine how to proceed.
Knowing what to build is a requirements-gathering exercise but everyone looks at the requirements with their own frame of mind and understanding of the domain, as above. Incremental releases can help to mitigate those problems, but that means that there is still a certain point near the beginning of a new and ambitious project when you need a proof of concept to scaffold out the application and show the central functionality. If that central functionality is complex enough your prototype/proof of concept might be a good time to take on some technical debt.
If you have a deadline, and the consequences of delivering less quality are lower than than the consequences of missing the deadline, then it is time to consider lowering quality if you think it will let you hit the deadline. When put in those terms it seems straightforward, but the rub is in figuring out the true consequences, and who those consequences impact. Missing a deadline could have significant consequences to your personal reputation, but releasing something lacking in quality could be worse. It could cause issues for the company as a whole doing long term damage to relations with that client or the company’s reputation.
A clear picture of the consequences requires an understanding of what your team can truly accomplish. In scrum you’ve got velocity. If you are doing a more waterfall-style methodology you’ve got normal hour estimates for tasks. In kanban it’s cycle times. Each of these measures is the way you can try to estimate whether you can complete what you need to within a given timeframe, assuming that you know the tasks involved. The biggest issue I’ve always seen is that when you make your estimates and decisions, you know you need to do A, B, C, and D, but did not see the need for items E or F. This can have a particularly serious effect if the issues are interdependent. If you realize you need E or F too late and it blocks other tasks, you might not even have an opportunity to make the decision on quality versus time, since it is effectively taken out of your hands..
Intelligent usage of technical debt can help you achieve things that seemed impossible in the given timeframe. However it needs to be a reasoned choice. Once you have taken on technical debt you need to (1) know you did it and (2) have a plan to deal with it. Once you have taken on that debt you end up in a position where your options for taking on additional debt are limited. Since quantifying technical debt can be difficult (tools like Sonarqube try), but a reasonably close accounting can be good enough to tell you where you stand in regards to an ability to take on more.
Remember that technical debt is an important tool for professional developers. No need to build half a monument to software architecture then have the project canceled. Jerry-rigging something that adds value but everyone understands has limits and liabilities going forward can be a great success under the right circumstances.