[andhof-mt]

But your thinking like a programmer. Some times it is also valuable to think like a business.

What is the goal of this software? Ship now? MVP?

Are we trying to polish the software? Or just get it to work? Is it a prototype?

Some thoughts to take into consideration.

[jeremiep]

It could also be a double-edged sword. I've seen it happen more times than I can remember.

Management sets a clear deadline, we rush the code to get it done by its due date. Then the product sits there for months doing nothing while we're in between projects wasting time away. Half a year down the road we get asked for support because some things broke which would've been working fine had we taken the proper time to built them.

From personal experience, most businesses don't think in terms of maintenance and debugging. These are costs which can very quickly add up to way more than the saved development costs.

[goshx]

> Half a year down the road we get asked for support because some things broke which would've been working fine had we taken the proper time to built them.

This seems to be so common. Almost every project seems to break or have issues at some point and the excuse is always the same: oh we didn't have time to do it properly. It makes me wonder if that is indeed always the case. This leads to a question... are there projects that are done in enough time so that they won't break?

[jeremiep]

I've made quite a few products that were ship-and-forget over the years. Every single time I had sufficient time to think about the architecture and focus on the simplicity of things.

But I agree this isn't the norm.