Technique Fragments
Technique FragmentsI'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 GoProverbs.) 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 ? (XpXtudes 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
See NoProcess ArtifactFragments
EditText of this page
(last edited July 8, 2012)
or FindPage with title or text search