Technical Debt and Quality in Software Engineering

When deciding to take on Technical Debt in a code base, one must consider the ability to change in the future. The more Technical Debt you take on, the tighter your disciplines must be. It is best to do more testing, pairing and refactoring. Technical Debt is not a license to make poor-quality code. Whenever we change a code base, we should ask ourselves these questions. Is the code clean? Is the code tested? Is there a learning goal or event? Is there a payback plan? Is the business informed?

Quality is not an independent force in the universe; it depends on what you choose as your frame of reference. Low technical quality is not a crisis but an expected, normal state.

Technical Debt is a proposed solution for insufficient information about a problem. Decisions about Technical Debt are based on actual project constraints, and while they are risky, they can also be beneficial. It is a strategic decision that should not be used as an excuse to deviate from the best-known practices in Software Engineering.