A paper, published in 1984, by BarryBoehm, TerenceGray and ThomasSeewalt.

http://portal.acm.org/citation.cfm?id=802007&dl=ACM&coll=portal

"In this experiment, seven software teams developed versions of the same small-size (2000-4000 source instruction) application software product. Four teams used the Specifying approach. Three teams used the Prototyping approach. The main results of the experiment were: Prototyping yielded products with roughly equivalent performance, but with about 40% less code and 45% less effort. The prototyped products rated somewhat lower on functionality and robustness, but higher on ease of use and ease of learning. Specifying produced more coherent designs and software that was easier to integrate. The paper presents the experimental data supporting these and a number of additional conclusions."

Translated into NewSpeak, the article says that at the beginning of every software project, the project manager must select one of the following processes:

	* CodeAndFix - one year of slamming code, one year of debugging
	* BigDesignUpFront - pray to paper to save you from coding
	* EarlyPrototyping - Build prototype versions of parts of the product. Exercize the prototype parts to determine how best to implement the operational product. Proceed to build the operational product, and again rework it as necessary.

Observe that "Specifying produced more coherent designs and software that was easier to integrate." The missing ingredients we have since learned are TestDrivenDevelopment, refactoring, and FrequentReleases.


----

''Any thoughts on how the study would scale to a larger "real" application?''

I only skimmed it, but I suspect from the Abstract that the authors' opinions, at that time, was that EarlyPrototyping for a big project represented raising your foot until it centered in your cross hairs, and slowly squeezing the trigger. They found Specifying to lead to "more coherent designs". If this represents our OpenClosedPrinciple, nothing on the Prototyping side incremented that in.