Ask HN: As a CTO, what is your most frustrating problem with technical debt?
For the last 5 years I&#x27;ve worked primarily with startup CTOs and enterprise directors&#x2F;VPs to build teams practices XP, lean product development, and user-centered design.<p>My advice to them, and my philosophy on this topic, is that technical debt is just that- debt. It&#x27;s not a dirty four-letter word to be avoided, it&#x27;s something to be managed the way you manage actual financial debt. There are some projects where the software you build will be self-contained (no dependencies), will require minimal changes in the future, or it may have a short shelf life (e.g. it&#x27;s a stopgap before you cut over to a new system). In these scenarios, accruing technical debt isn&#x27;t the worst thing in the world if it allows you to reap business value faster.<p>When you&#x27;re building software that&#x27;s going to live long-term, or that drives core parts of your business (and therefore will need to change frequently as your business changes), technical debt needs to be tackled early and often. It&#x27;s ok to accrue technical debt in the short term ONLY if you make that decision consciously knowing that you&#x27;ll need to address it later (e.g. I had a client that needed to release their software for a trade show, so we accrued tech debt and created tasks to track every piece of debt we&#x27;d want to tackle later, and then prioritized that work immediately after the trade show).<p>That said, it&#x27;s also important to be clear about what constitutes tech debt vs what is over-optimization. Outside of libraries and frameworks, I don&#x27;t really need the software to be &quot;perfect&quot;. I need it to be clear enough, tested thoroughly enough, and easy enough to change to maintain a high velocity. If a part of the code has become spaghetti-like, or if we see code duplicated more than 3 times, or if we have disparate code that&#x27;s too closely coupled to easily make changes, that&#x27;s technical debt worth tackling.<p>The vast majority of organizations I&#x27;ve worked with typically think much shorter term, which is why they find themselves repeatedly accruing technical debt to the point where changes to the system occur at a snail&#x27;s pace. It takes a lot of discipline, and coordination between IT and business, to practice what I&#x27;m describing, but that&#x27;s the ideal that I strive for and advise my clients to strive for.