Whatever the training task, the pace must be ruthlessly brisk. The learner should be expected to build at the same pace as an experienced developer. The difference between the learner and the wizard is that you expect the learner to make a lot of mistakes. The system as built may be awkward or not handle error cases properly. That's okay. Training research shows that if you get speed now you can get quality later. But if you don't get speed you will never get quality in the long run. We practice this technique in 6.916, Software Engineering for Web Applications, our course at MIT. Each student builds five database-backed Web applications during the 13-week semester. The first few that they build, during the course of the problem sets, are not necessarily elegant or optimal, but by the end of the semester they've become remarkably proficient, especially when you consider that each student is taking three or four other classes.
The bold part of this article caught my eye. The author seems to be encouraging the idea of going out and doing a lot of cuts, very fast, and if you do them fast enough and often enough you'll soon be able to handle a bokken.
Granted he's talking about software development but learning is learning. This seems to fly in the face of the way I've been taught Aikido which tended to emphasize consistent and regular practice. In fact, quality has always been emphasized before quantity. Always! Anyone ever put this to the test or is it something we've just accepted as a truism?
The full text of the article, which is really about management, not training, can be found at http://www.arsdigita.com/asj/managin...re-engineers/.