I'm thinking these days that we really only ever use techniques in fragments, that we don't use a technique fully in normal situations.  That is, in a real situation, we paste together fragments of different techniques, some invented, some known, with glue consisting of actions that are just that - glue.  

This may have implications for teaching people techniques - CRC cards, semantic modeling, use cases, etc. Instead of asking them to master a full technique and then being disappointed that they don't use it that way, only ask them to master technique fragments, and know when to apply those.  It may help me get past the ShuHaRi bottleneck. --AlistairCockburn

I think the misunderstanding was on your part in thinking that "to master a full technique" and to strictly adhere to a full technique was the right thing to do. It is not and there is no such technique able to address all the situations in its domain (not XP, not agile, not RUP, not use cases, not CRC, not anything else ). Authors, methodologists and zealots should have a better understanding of the limits of their greatest and dearest, and they should actively seek to establish such limits (very rarely it so happens in practice).

So you have to trust your students that they will know better what's best in each situation they face. To help them more, you should come with examples and try to define where a particular technique is not likely to work, or is simply not the most adequate/efficient solution. 

This is the way it works in performance chess training. The master adapts to the style of the student and not the other way around (the students that just copy the style of the master are not likely to make performance). Then a student needs to understand and be able to apply all the different techniques and styles, and he needs to be able to combine them at will, and come up with the best way to address each particular position. Programming has a lot of characteristics in common with the games of chess: it is a matter of science, art and craft, it is very complex and diverse, requires substantial individual creativity, and the list could go on. So a good programmer should have a lot in common with a good chess player, he has to have an extensive cultural background and to know lots of different things and perspectives, and he should first adapt to each concrete situation and be able to choose the best way to deal with it. Therefore it is likely he/she will not fully apply technuiques but combine different TechniqueFragments, and this is the right thing to do.--CostinCozianu 

''Thanks for the comparison --AlistairCockburn''

That metaphor is consistent with the way I find myself practicing (for instance) refactoring - rarely doing things ByTheBook (Martin's book in that case) but more often using the book as a source of good moves and combining them with other good moves learned independently. (I'm also reminded of GoProverb''''''s.) On the other hand, don't chess masters (or chess students) ''also'' get good at chess by doing what we now call "etudes", where doing things ByTheBook is crucial ? (XpXtude''''''s to use the official terminology.) On the gripping hand, they also get good by doing other things for which I'm not sure we have equivalents in software design - like studying great games of past masters, or solving chess puzzles, or creating chess puzzles... -- LaurentBossavit

''But what about ReadingCode? I'm always amazed at how little code programmers actually read (other than code they're modifying and even then it seems to be the minimum amount they could get away with).  Studying great code, or great designs, is surely a way to improve and reading bad code or poor designs is a way to see and learn what doesn't work. -- TedYoung

* This is one of the great advantages of the OpenSource movement, lots of GreatProgramsToRead. And if you choose to work on OpenSource projects, you even get code review and mentoring. (There is no need to go out of one's way to read bad code. BadCode will be thrust upon you in your career.)

I practiced fencing briefly when I was 18.  One day, I complained to the instructor about doing all of the drills with such precision in the precise way he wanted them done.  He said, "You do the drills my way and you will learn exactly what thing means, and how to do things.  When you go out and compete, forget the drills, just try to win."
It sounds very ShuHaRi to me.  Follow the rules unbendingly until you can follow them perfectly.  Then ignore them.  -- NickArgall

----
See NoProcess ArtifactFragments
----
CategoryLearningMethods