I generally agree with you, but it really depends on the context. You can never abstract the development side from the business needs, and those trump everything.
In a fast business with a very small team and a very short runway you often have to sacrifice quality in exchange for putting something out there. If something doesn't come out of the oven, there's no "long term". At that point, the choice makes itself. That's probably why a lot of people will, likely rightfully, claim that startups don't need to be highly technical unless it's where their competitive advantage will come from (and in the words of Mark Suster, 90% of startups do NOT fail because their tech wasn't good enough).
On the other hand, in long-term projects that have enough budget to survive for a while, you can shift priorities and focus on quality as appropriate.
The release process is also really important here. In web/saas you can fix things very fast behind the scenes without the customer being aware of it (Etsy claim to make what.. somewher around 100 checkins into production a day?). In mobile / boxed you have to be a lot more careful. Nobody wants to wait 2 weeks for Apple to approve your patch when a major scenario is broken in your app.
Of course, if you can have both wonderfully clean and extensible code and get that done exactly as fast as poorly written code, that's the preference.
In a fast business with a very small team and a very short runway you often have to sacrifice quality in exchange for putting something out there. If something doesn't come out of the oven, there's no "long term". At that point, the choice makes itself. That's probably why a lot of people will, likely rightfully, claim that startups don't need to be highly technical unless it's where their competitive advantage will come from (and in the words of Mark Suster, 90% of startups do NOT fail because their tech wasn't good enough).
On the other hand, in long-term projects that have enough budget to survive for a while, you can shift priorities and focus on quality as appropriate.
The release process is also really important here. In web/saas you can fix things very fast behind the scenes without the customer being aware of it (Etsy claim to make what.. somewher around 100 checkins into production a day?). In mobile / boxed you have to be a lot more careful. Nobody wants to wait 2 weeks for Apple to approve your patch when a major scenario is broken in your app.
Of course, if you can have both wonderfully clean and extensible code and get that done exactly as fast as poorly written code, that's the preference.