> It's really surprising how often the “quick” approach turns out to be slower than the “right” approach. It depends on what is done fast and what is done more

> It's really surprising how often the “quick” approach turns out to be slower than the “right” approach. It depends on what is done fast and what is done more thoughtfully. For example, if the general architecture is thought through carefully, individual modules can be built more hastily and later rewritten. On the other hand if the architecture is unsuitable for the problem, then it matters little how well tested or high quality any of the code is, and overdoing code quality will be a waste of time. It comes down to judgment and tradeoffs (like everything in engineering). I like the concept of tech debt because it is a way of describing a class of tradeoffs.