UPDATE: Here is a blog post where one of the metis students talks about their experiences with Error-Driven Development
I'm currently teaching the second cohort at metis, a Ruby on Rails bootcamp, and a technique I've been using to teach students Rails is something I've dubbed Error Driven Development.
The main idea behind Error-Driven Development is that since Rails provides such wonderful error pages, we can teach students how to use Rails by getting them to generate the simplest error to push their applications forward. This allows Rails to act as a guiding force to help students understand what Rails does and what the next step is.
An example of this would be to create a page that shows a list of galleries. The first step is to have the students visit "/galleries" which throws a routing error. After adding the route, Rails will complain that no GalleriesController exists. After adding the controller, Rails will complain that there is no index action. Finally, after adding the action, Rails will complain that there is no index.html.erb template.
One of the main benefits I've found to using this technique, is that it closely mirrors the process of Test-Driven Development where the developer is trying to create a failing test case and then performs the minimal amount of work to make the test pass before moving on to the next failure. I've found that by teaching Rails in this way we get students already thinking in a test-first kind of mentality which allows them to more quickly pick up Test-Driven Development on their own outside of the bootcamp.
As an instructor, seeing this result has been extremely gratifying. I remember when I first started learning Test-Driven Development using cucumber around 5 years ago that I found it very difficult. It was hard to undo my process for writing software that I had created over the prior 12 years before I was introduced to Test-Driven Development. By introducing a very similar process for those first entering into the world of programming we created a kind of cushion for making the transition much easier than the one I faced.
Outside of learning how to program, I wouldn't suggest Error-Driven Development as a means of writing actual software. I'd much rather write software via Test-Driven Development, since it will provide the benefit of possibly preventing the breaking of my application, but I've definitely added it to my toolbox for teaching others how to write software.