I posted earlier on an XP mailing list thread - here's more:

Orthogonal to ROI?

egb:Yes, these really are different values - but I am not claiming that they are completely independent values. There is certainly a time value to money, meaning that if you can reduce the time-to-availability, there is indeed an economic value. However, I would argue that minimizing time-to-availability is not necessarily equivalent to maximizing return on investment.

Time to availability is perhaps the most important value.

Egb: In some domains, yes, but it is not fair to generalize this to be the primary value in all domains. If I'm writing embedded software for a toy, accelerated time-to-market has value but there is likely greater value attached to reducing per-unit cost...shaving off cents will make a difference in a mass market item (i.e. spending time to squeeze code into a smaller ROM footprint). If I'm writing an avionics control system, I probably have some hard final code complete date and accelerating availability will likely contribute to risk reduction (and thereby will have some economic value) but my return on investment will likely be more impacted by architectural initiatives that drive to economics of scale.

ok - first off, you picked two rather extreme examples. I'd warrant that most people reading this group are building more prosaic business systems - and in that case, your examples don't mean a lot. But even within those systems:

• embedded software in toys or games - if you don't get something in front of the customer fast, you have no market. The toy and game markets are perhaps the prime example of time to market being king; spending a lot of time on design in that space will ensure that you never get a product sold, plain and simple.
• Avionics - economics of scale in the manufacturing sense don't apply the same way to software. we can assemble large factories with machine tools and robots to spew out parts; we can't do anything even vaguely like that in software. I'm not at all sure that I get your point here at all, honestly

...

Why? Because you can then tell whether a development project is on track or off track. Being on or ahead of time has a value of its own, and tends to build ROI (or prove quickly that there will be no ROI).

Egb: yes, but my point is that this does not necessarily optimize ROI....reducing time-to-availability does force early risk identification, which is certainly an element of ROI, but it is not the only element of ROI: what is outsourced? How small do I squeeze down my development staff? Can I achieve some economics of scale by earlier architectural investigation?

IMNSHO, if you are considering outsourcing of development, you better outsource the whole thing. Trying to run product management and design here, and development there (where there is 12 hours in tz distant and the culture is different as well) is a just silly. Those who think otherwise will answer differently when asked "Why not outsource marketing?", or "why not outsource all C level staff?" Economies of scale? In software? I truly have no idea what you mean by that. Large teams of developers are a mistake.

...

and - not to put too fine a point on it - if the cost of developing software gets to be that much of a problem as the business grows, then there is a severe business problem that needs to be fixed.

The cost is a symptom of a much bigger problem in that case.

Egb: if you take the automotive industry as an example, reality is that cost is increasing - and not just the total dollars spent, but the relative dollars spent as a percentage of the cost of a car.

Egb: Does this constitute a

If their costs are rising in a well understood business, they have a problem. It's truly that simple. I don't know what they are doing wrong, but I'm sure that they are, in fact, doing something wrong.

Second, getting features in front of end users quickly is optimizing. Getting them there slowly after some sort of complex ROI process is a fools errand. Why? Because in general, without feedback from actual users, it's unlikely that software that solves real problems will be produced

Egb: so, I think we have the two basic issues at hand: first, you would seem observe that time to availability is the most important value - I would agree with you for certain domains, but I would not agree to the generalized statement of applying this to all domains; second, you would seem to suggest that minimizing time-to-availability is tantamount to maximum ROI - I would agree that there is an influence, but I would again argue that there are many other elements that make up an ROI.

IMHO, it's true for any domain I can think of. In domains where something seems to prevent it, I suggest that the entire development model is screwed up, and needs fixing.