>"But the business objective may call for 'a quick iteration for demonstrative purposes'."
Most developers I've worked with are smart enough to know quick hacks are fine in small doses, but if they become the norm you end up with a great deal of technical debt, which can ultimately cripple the productivity of a company.
From the perspective of managers who aren't familiar with technical debt, the 'quick win' is always going to seem like the best option. It's up to the development team to strike a balance between 'the quick way' and 'the right way', and whilst some managers may get frustrated on the occasions when 'the right way' wins out, in the mid to long term they benefit too, though they may not understand why.
Most developers I've worked with are smart enough to know quick hacks are fine in small doses, but if they become the norm you end up with a great deal of technical debt, which can ultimately cripple the productivity of a company.
From the perspective of managers who aren't familiar with technical debt, the 'quick win' is always going to seem like the best option. It's up to the development team to strike a balance between 'the quick way' and 'the right way', and whilst some managers may get frustrated on the occasions when 'the right way' wins out, in the mid to long term they benefit too, though they may not understand why.