Okay.

I think that the common definition of success with regard to software projects -- did it meet its original schedule? did it meet its original budget? did it meet its original goals? -- is fatally flawed.

A better definition of success comes from asking "Does the project provide real business value to the organization? Is that value greater than the investment of time and resources required to build the project? How soon did the project begin to produce that value?"

The dangerous part of that definition of success, besides that it's totally at odds with the time/budget/scope question, is that it depends on what's valuable to the organization.

You may be able to guess what's probably valuable in broad terms eighteen months in advance, but I've never seen the specifics stay static for more than a few months at a time, and certainly not in the detail necessary to write software that takes eighteen months to complete.

Though your point may be somewhat tangential to a test first or even design first discussion, I do take it.

One of the rewards of this forum for me is coming across an insight or perspective that has some novelty and fitness both.

Does an actually existing implementation provide value is exactly the question, and how quickly do we realize such value? Nimbleness and ease of reuse and ease of change are valuable, because both business needs and requirements change.

One of the points that I have seen sundial effectively make before on other threads is the consequence of business needs and the higher order problem of serving business needs effectively through the building of networks and processes and not just somewhat-trivial specific apps.

Also, to your point, the higher order problems of a google to take one example are not just the apps but the entire network and the nimbleness.