Theory:

As the stories of disasters in product develop piled up, Experts tried to learn from the mistakes and find a better way.  Typically, the solution was to do better planning, so the future disasters could be avoided.   In the best cases, the projects ran better after people had time to think about what they were really doing.  In the worst cases, mountains of plans and specifications that required a truck to transport were delivered to the development team, who realizes that the requirements have changed since some of the documents were written.  Sometimes just reading all the documents could take more time than doing the project.

Starting with the iterative design methodologies and amplified in the Agile and Lean methodologies is a completely different solution to the problem.  As an analogy, assume you have a cannon, a barrel  of cannon balls and a barrel of gun powder.  If your goal is to hit some distant target, all you have to do is point the cannon in the right direction, then calculate the angle of elevation and calculate how much powder to use.  The math is actually quite complicated because of the number of variables in a real world system.  You have to use some kind of chemestery to calculate the force the gun powder will generate.  You need the mass of the cannon ball.  You need to know the wind speed a each point along the path of the ball.  You need to know if the cannon is perfectly straight and the ball is perfectly round; small deviations will cause the ball to spin.  An then, of course, there is the triginomitry, which is a lot messier, if the target is at a different elevation.

 Your chances of getting it right on the first try are minimal.  Your chances of getting it right in a dozen tries are not very good UNLESS...   Unless you watch where the ball lands each time and try to compensate.   If you do that, you don't even have to try the calculations.  In real life, the calculations could take days, but trial and error might get the mission accomplished in minutes.  This is "ready, fire, aim".  It is not the quick-and-dirty method for people who can't do math.  It is a faster, smarter, cheaper way to get the job done.

 Did you read the page on universal laws?   Both laws are involved here.  The first law applies, because this is a complex system.  The world is full of systems that seem like they should be simple, but they aren't.   The second rule tells you how to deal with a complex system, you use feedback.  The solution to this problem follows directly from the universal laws.

 Note:  There could be constraints that would make the calculation more valuable.  What if there were a hospital between you and the target?  What if there were only three cannon balls?  What if the old cannon might just explode after a couple firings.  In real life, there are projects with such great risks that you can't afford to make a mistake.

Real-World Application: Specification

In development projects, Ready Fire Aim applies to specification.  It is not humanly possible to perfectly specify any useful product.   But if you have a way to test the product, you can make corrections.  Classical waterfall theory says, "No, you have to specify the product really well, because the cost of changing it late in the development cycle is too high."   I have never seen a specification effort that has proven to be anywhere near perfect.  But you can spend any amout of money trying to get there.  So, here are the lessons:

1)  Specifying things up front or correcting based on feedback are options that you weigh by their cost, and by the risks.  It is often cheaper to do a quick specification job followed by multiple iterations with corrections.

2) You can configure your development effort to minimize the risk of making changes.  Locking-in later is a cornerstone of the Lean movement.