I’ve worked in a startup where they were unable to deliver integrations in time because previous work had been done “quick and dirty”, and significant amounts o

I’ve worked in a startup where they were unable to deliver integrations in time because previous work had been done “quick and dirty”, and significant amounts of money were lost as a result. Don’t kid yourself. That is technical debt, it was our fault. Technical debt isn’t “bad code” it’s what stops you from shipping features; and it’s more important for startups to manage, not less. What youre referring to is very early stage stuff, where the total LoC is so trivial that a few people can just remember all the details of it in their heads, so it doesn’t matter how messy it is. ...true, but there are finite physical limits to humans; you can only keep doing that for so long before you flub it up, and lose a lot of money for your employer. This is one of those moments that people just flat out fail to have intuition about. Same process, same results right? Nope. Same process with diminishing returns <— reality of software engineering over time. So specifically: > After all, whatever you think of the code or design decisions you've found, it has clearly justified itself just on basis that the company is successful enough for you to be there finding it. This is wrong. It was the correct decision/code at the time for the scale at the time, which, since you are there looking at it, it is probably no longer suitable for. Not intuitive is it?