> You can write the shittiest spaghetti code in the world, and if you never have to build upon - or touch it again - you took on zero technical debt. I don't r

> You can write the shittiest spaghetti code in the world, and if you never have to build upon - or touch it again - you took on zero technical debt. I don't really agree with this view; it may seem pedantic, but I think it's better to consider that case as tech debt. In my experience, it's incredibly uncommon to write code and never touch it again -- particularly if you elect to cut corners in the interest of getting something out the door quicker. That code inevitably either gets retired because it's not being used (your debt was forgiven), or gets built on top of (your debt starts to compound). If you make a decision to lower the quality bar because "we are not going to touch this again, so it's not tech debt, so it doesn't matter", then I think you're fooling yourself. Instead, I think it's better to assume that you're taking on tech debt (you almost certainly are), apply all the best practices around managing that debt (i.e. catalog it, be aware of your overall debt level, and be aware of tech debt in critical systems), and be happy if your debt is later forgiven if you miraculously never need to touch that code again. Maybe there's a narrow sense in which this position is technically/semantically correct, but I think more often than not, this position is going to hurt you more than it helps.