I've ranted about this before. Everyone would like to have infinite time to write the best possible code and do everything right. In a business, particularly a time constrained or financially constrained one, the art of running the business entails deciding which corners to cut, what tradeoffs to make.
Ironically, startups hire inexperienced people who often over-peform but sometimes underperform. A less risky approach would be to spend more (cash or equity) to hire people who are more of a sure thing. This could be called "execution debt" but it is accepted as visionary and associated with believing in people and being able to sense talent.
Tech (architecture, code, devops, etc.) is no different. A highly skilled team will be able to make the right tradeoffs and cut the right corners.
Tech debt is usually what people call something that appears in hindsight to have been the wrong corner to cut, however one would need a time machine to understand why the decision were made and what was competing for time/attention/resources and why.
Engineering is the discipline of managing tradeoffs to create something.
When working with a codebase that appears to be technical debt, the important thing to ask is what the options are today to address it. It may be beautifully written, clean code that uses the wrong abstractions, or it may be a solid architecture with some ugly code and style that needs to be addressed. Lots of people have biases due to their own preferences, but the thing to rememeber is that chances are the code was not made by someone with infinite time and perfect knowledge.
Ironically, startups hire inexperienced people who often over-peform but sometimes underperform. A less risky approach would be to spend more (cash or equity) to hire people who are more of a sure thing. This could be called "execution debt" but it is accepted as visionary and associated with believing in people and being able to sense talent.
Tech (architecture, code, devops, etc.) is no different. A highly skilled team will be able to make the right tradeoffs and cut the right corners.
Tech debt is usually what people call something that appears in hindsight to have been the wrong corner to cut, however one would need a time machine to understand why the decision were made and what was competing for time/attention/resources and why.
Engineering is the discipline of managing tradeoffs to create something.
When working with a codebase that appears to be technical debt, the important thing to ask is what the options are today to address it. It may be beautifully written, clean code that uses the wrong abstractions, or it may be a solid architecture with some ugly code and style that needs to be addressed. Lots of people have biases due to their own preferences, but the thing to rememeber is that chances are the code was not made by someone with infinite time and perfect knowledge.