Nature works by iterative recursion, not recursive iteration.
Take our brain as an example. The "recursive base case" is pretty simple just a type of neuron with information to send to its neighbouring neurons. Sure, there are different types of neurons, and different messages, but they pale in comparison to the vastness of the collective network which they form.
Amazingly, this recursive network gives rise to a heirachy, through which consciousness can arise.
However, nature didn't get here overnight. She made one brain, then looked at the favourable characteristics of that brain, and tried to specify rules (in the form of genes) to make a better brain. Over time, and billions of brains later, she ended up with a highly efficient, yet ever improving machine.
This is iterative recursion.
On the other hand, recursive iteration tries to add recursive rules to points in an existing network/system. In nature, this is akin to trying to add an extra DNA base to a gene. All too often, things don't coordinate well, and the pairs don't match. We have a mutation.
We've seen the same happen with our own systems. Examples range from the Sampoong Department store collapse, to Microsoft Bloatware. Essentially, modifying a system that wasn't set up with the degree of necessary robustness.
This is recursive iteration, and it must be done with extreme care.
Hence, when it comes to building an artificial system, it pays to follow the principle of iterative recursion as nature does. Some people interpret this as "fail fast, fail early", and that works, but at the cost of your first X subjects.
I prefer to approach this in a different way. Set up a robust system that is resilient to recursive change. In software, this could mean controlling (and limiting) dependency scope. In business, this could mean planning out your core revenue streams and having a system to expand or contract your marketing decisions based on feedback.
Of course, this means a lot of planning and stressing and general malaise and indecision in the early stages, but it pays off in the long run. Fortunately for us, once we get those initial rules in the system right, it becomes very scalable.
This is where the "fail fast" mantra has it's place, especially in learning. Use it to get up to speed. Bang out those weekend projects that may have limited impact but will keep the learning curve steep.
When it comes to the major projects, definitely take the measured approach, and start with a robust architectural foundation. It may be boring and tedious, and it may take you many days with little to no measurable progress. But holding back from slapping on the nearest or pretty-est solution will pay off in the long run by helping youavoid the Fail Whale.