Essentially, in a software development project, there are three variables we can play with: quality, scope, and timescale (which is directly linked to cost, both in terms of development cost, and opportunity cost).
Quality is the easiest one to cover. Most of the time you don’t want to muck around with quality, though, by not acknowledging it explicitly, it’s often the one that’s sacrificed. Dropping quality is essentially an exercise in deferring cost. If we cut corners, then we’ll build up technical debt, which will have to be paid off later. So dropping quality increases the long term total cost of ownership, because it’s harder to fix bad code that customers are already dependent upon than it is to write good quality code in the first case. One way to trade off quality vs opportunity cost (speed to market) is to explicitly accept that we’re building a prototype in order to test the market, and that the prototype is likely to be thrown away when we build the ‘proper’ system.
So I guess the first question
