Set-piece play General background, part 3
In football (or soccer, if you’re American), there is a special kind of situation in the game which is called ‘set-piece play’. A direct free kick is a good example: if the game was interrupted after an attacking player has suffered foul play, the attacking team can start the game with a free shot, the ball lying in a resting position. It’s the kind of situation that often leads to scoring; part of the reason is of course that the shot can be taken undisturbed by opponent attacks, but it’s also because such situations can be practiced and planned much better than in-play situations. Set play leaves you more in control, and there is a limited number of patterns, for which you can train separately.
(In German, the term is Standardsituationen, literally ‘standard situations’. This emphasizes the aspect of a routine pattern even more.)
Thus even if a team has to fight a stronger opponent that is difficult to predict, there is at least one good strategy towards winning: practice hard to use set play as effectively as you can.
… and coding
And what goes in sports also works in coding, TDD-style. Even if you’re facing a large and unwieldy code base, one which was grown without automated tests in mind, or one that has proliferated out of any proportion, you will still regularly encounter certain situations in which you can be at least partly in control: that’s where you can score.
The kind of situations we have in mind have some characteristics similar to set-piece situations in football:
- they happen fairly frequently;
- they can be recognized easily (more or less);
- because they have a typical structure, there is also a typical strategy for each of them, which is well-known and time-proven.
The catalog
For our approach we have cataloged eleven such situations. (It’s a pure accident that this number equals the number of players in a football team. ;-) We use them for several purposes:
- to teach how to recognize the crucial points in a real-world code base where you can make a start and write some test cases;
- to strengthen prospective memory: remembering to write tests when you come along a specific situation (it is easier to form an intention to do something, like writing a test case, if you have a specific scenario in mind);1
- to make sure that you have a strategy for finding test cases once you’ve recognized a suitable place;
- to have some starting points for ‘developing the eye’ — building up the cognitive capacity for finding ways to write tests;
- to have some variety of occasions for developing a habit of writing unit tests (and writing them first).
The catalog is our central element in all this. (You can download it in the downloads section here on this site.) We have devised several exercises which are all centered around it, and we provide it as a starting point that you may extend after some time.
On this blog, we will go into the technical detail with respect to the entries in the catalog; we will also add some background information about the didactics and the psychology behind our approach.
This post belongs to a three-part introduction to our approach. Read the other parts here:
- The didactics of test-driven development
- TDD as a skill and habit
- Set-piece play (this post)
1 See Peter Gollwitzer, “Implementation intentions. Strong effects of simple plans”, in: American Psychologist 54 (1999), 493–503.
blog comments powered by Disqus