I don't really consider technical debt to be about things that make the code base harder to reason about (unreasonable?). That is an important architectural poi

I don't really consider technical debt to be about things that make the code base harder to reason about (unreasonable?). That is an important architectural point but I think of it as orthogonal to technical debt. To me, technical debt is about the trade-off of short term progress for long term flexibility of the code base. Essentially, the need of the business to ship -- side note: I wrote that as shit initially. Freud would be amused. -- the feature immediately outweighs the need of the business to write maintainable code. So, you expend fewer engineering resources than you should now and you spend more than you would have later. Basically, you borrow against the future productivity of your engineering team. So, to me, it's about doing less work now and more work later. That can be a conscious decision or a consequence of ignorance. Things like choosing the wrong abstraction are about being ignorant of the problem space.