The Programming Dojo
I am here in Sheffield, UK at XP2005. My favorite event so far was Laurent Bossavit's Coding Dojo. Apparently it's based on some of the ideas from Pragmatic Dave Thomas' blogs. PragDave[?] talks about simple coding exercises that one would work over and over again, the same way that martial artists repetatively practice their moves in forms called: kata.
In Laurent's workshop, one of the presenters, Emmanuel Gaillot, used TDD to build a tiny bit of Conway's game of life. He wrote in Ruby. The beauty of this was that most of the attendees did not know Ruby, but they were able to follow what Emmanuel was doing, and make recommendations regarding the design. Most of us learned a little Ruby too.
Now I have been doing one particular Kata for several years now. I've done it hundreds of times. I do it at conferences, customers sites, trade shows, etc. It's the BowlingGame[?]. I've done this so many times I can do it in my sleep. The funny thing about it is, though, that I still make tiny little improvements. This doesn't happen very often anymore, and the improvements are not significant; but they are there.
I was a martial artist for several years. Most recently I studied Jiu Jitsu. The experience of repeating and repeating a single set of moves is intrinsic to the way any martial art is taught. Beginners learn by doing, not through lecture. They practice and practice, and practice. They practice with their peers and with their seniors, and with their juniors. And over time they can gain a level of skill that's quite respectable. And yet, even at the pinnacle of (my) skill, I found that I was making tiny little improvements from time to time. I would experience tiny little aha! moments - just like when I do the Bowling Game.
Recently we brought three new apprentices in to the office. I started them out with a simple exercise (I might call it a Kata now). I had them write a simple algorithm to compute the prime factors of an integer. I gave them the initial test cases, and asked them to make each one pass in succession by making the simplest possible change. I advised them that if they did this carefully, they should arrive at a general solution that is no more than three lines of code in it's core algorithm. (You can see this Kata here.) Each of the apprentices did this excercise, and learned a lot about TDD, and simple design. Next I had them do another exercise to add a !timeofday widget to FitNesse, and then convert it into a plugin. They each did that too. That gave them the necessary knowledge and skill to begin working on the next project.
Now, I think I am going to drive these apprentices to repeat these exercises as Kata. And I think I'll introduce new kata for them. Imagine a kata for recursion, a simple tree search. Imagine one for tail-recursion, a factorial program. Imagine a simple Kata for sockets, or multithreading, or regular expressions, or ... You get the idea. By repeating and repeating these same exercises, we sharpen our skills, we train our bodies and our minds to respond to the disciplines of TDD and simple design. We wire, and rewire, and rewire, and rewire our neurons to react in the right way.
As you can see, I think this is very powerful.
Remind me to tell you about the Randori session that Laurent did at the dojo!
I've recently been planning to deepen my understanding of OOP and "the right way to do things" in OOD/OOP. I have a heap of books on the subject(s), some read and some still waiting for their turn. However, I've had a hard time figuring out how I should proceed with the knowledge I'm gathering. Of course I have intended to do some practicing by actually coding, but the projects that I've had in mind have so far seemed somewhat unmotivating or confusing.
Now I realize that they have been oversized to fit my learning needs. I have simply not known what I should begin with, and thus have not begun with anything. Also the idea of repeating the same (simple) "katas" has evaded me completely. Thanks to you and the PragDave[?] article you linked to, I now know exactly what to do.
Having practiced martial arts for a couple of years the idea now seems so simple and obvious I just have to keep wondering how I could not see the connection of these activities myself...
Now I realize that they have been oversized to fit my learning needs. I have simply not known what I should begin with, and thus have not begun with anything. Also the idea of repeating the same (simple) "katas" has evaded me completely. Thanks to you and the PragDave[?] article you linked to, I now know exactly what to do.
Having practiced martial arts for a couple of years the idea now seems so simple and obvious I just have to keep wondering how I could not see the connection of these activities myself...
The concept is nothing new to the various athletic activities that exist. For example, in baseball, a hitter may hit 100 hits off a tee, and then take 30 or 40 in live practice, all to supoprt the 3 or 4 at bats they get during a game.
Of course, software development isn't athletics. I get 40 hours per week to execute (play the game). Any practice I do takes away from playing the game.
So the question is how to structure the practice to most effectively support the game.
Would repeatedly doing a kata that exercises recursion be the most effective practice? Perhaps for a student, but I'm not sure if it would be for an experienced practitioner.
Yet, wouldn't a Kata be a useful technique for learning a new domain? Perhaps a kata that heavily uses swing. An experienced developer might practice this kata serveral times before starting a new assignment. Or perhaps a Kata for embedded C++, so that an application programmer might learn some embedded concepts before actually having to fight real hardware.
I suppose Cal Ripken's comment is most applicable.
It isn't "practice makes perfect". It's "Perfect practice makes perfect". Without the right exercises for the right job, we just discipline ourselves in techniques that aren't useful.
Mike
Of course, software development isn't athletics. I get 40 hours per week to execute (play the game). Any practice I do takes away from playing the game.
So the question is how to structure the practice to most effectively support the game.
Would repeatedly doing a kata that exercises recursion be the most effective practice? Perhaps for a student, but I'm not sure if it would be for an experienced practitioner.
Yet, wouldn't a Kata be a useful technique for learning a new domain? Perhaps a kata that heavily uses swing. An experienced developer might practice this kata serveral times before starting a new assignment. Or perhaps a Kata for embedded C++, so that an application programmer might learn some embedded concepts before actually having to fight real hardware.
I suppose Cal Ripken's comment is most applicable.
It isn't "practice makes perfect". It's "Perfect practice makes perfect". Without the right exercises for the right job, we just discipline ourselves in techniques that aren't useful.
Mike
I like that the kata are simple. They are simple to reinforce and refine the mechanics of TDD and simple design. While the kata may help an apprentice programmer learn about sorts, recursion and the like, the familiarity of the topic allows the journeyman and master to focus on the techniques of TDD and simple design.
Echoing MJV's comments, I have a heap of books on OO and hunger for the right hands-on exercises to develop fluency with the concepts. I'd welcome exercise books or articles by you and other OO greats.
I particularly love the idea of a set of exercises that are simple enough to do frequently and yet rich enough that they can continue to teach. It might be interesting to provide or point to rough rankings of the solution a la "apprentice", "journeyman", "master".
It's ironic that most people I know give themselves permission to practice physical things, but less so with intellectual things. The sports analogy should help. I've studied a number of martial arts, but your general insight seems to apply to all sports, arts, craft, cooking, etc.
I particularly love the idea of a set of exercises that are simple enough to do frequently and yet rich enough that they can continue to teach. It might be interesting to provide or point to rough rankings of the solution a la "apprentice", "journeyman", "master".
It's ironic that most people I know give themselves permission to practice physical things, but less so with intellectual things. The sports analogy should help. I've studied a number of martial arts, but your general insight seems to apply to all sports, arts, craft, cooking, etc.
It would be great to have katas they provided training and produced useful tools that we'd frequently use:
Possible katas:
* Implementing a unit-test framework. Example shown in Test Driven Development: By Example, by Kent Beck
* Simple email program
* Simple web browser, web server
* FIT fixtures
* Plugins for: FitNesse, Eclipse, Mozilla
Related article on practice:
Gamma on Patterns and Practice, A Conversation with Erich Gamma, Part IV, by Bill Venners June 21, 2005
http://www.artima.com/lejava/articles/patterns_practice.html
Possible trendy apprenticeship methaphor, trendy:
Jedi knight, a la Star Wars
Other practice-related metaphors:
emergency response training, firemen, special ops, etc.
I thinking about the bowling game, and other exercises that could be considered kata, I'm thinking there are 2 basic categories.
1) The exericise for which 80% of the benefit is delivered in the first application, and nearly 100% of the benefit is delivered by the 2nd. These are the activities with the fairly obvious solution. My observation of the Bowling game is that it falls into this category. While my coding style and technique may improve or adjust from application to application, I would argue that the majority of the benefit is transferred in the initial application (btw, I see the benefit as TDD / Simple Design).
2) Then there are the exercises that can be done over and over, for which a significantly different result may arise. These are the problems that either don't solve easily (there is no obvious design metaphore), or for which there are 3 or 4 reasonable solutions. I think these are the types of problems that would be great to use in a kata style exercise. -- Perhaps the different solutions might be a function of different languages. Solve the bowling problem in java, now do it in lisp. Do you have a different solution? Try Ruby now, then perl. In this case, perhaps the bowling game becomes something more illustrative.
Mike
1) The exericise for which 80% of the benefit is delivered in the first application, and nearly 100% of the benefit is delivered by the 2nd. These are the activities with the fairly obvious solution. My observation of the Bowling game is that it falls into this category. While my coding style and technique may improve or adjust from application to application, I would argue that the majority of the benefit is transferred in the initial application (btw, I see the benefit as TDD / Simple Design).
2) Then there are the exercises that can be done over and over, for which a significantly different result may arise. These are the problems that either don't solve easily (there is no obvious design metaphore), or for which there are 3 or 4 reasonable solutions. I think these are the types of problems that would be great to use in a kata style exercise. -- Perhaps the different solutions might be a function of different languages. Solve the bowling problem in java, now do it in lisp. Do you have a different solution? Try Ruby now, then perl. In this case, perhaps the bowling game becomes something more illustrative.
Mike
I think the value of a kata may be different than you are thinking. The solution of the problem is not as important as the suite of micro-decisions that was used to get to that solution. That suite of micro-decisions is the form; and I think there may be a lot of benefit to repetative memorization of that form. Students will internalize that suite of decisions by repeating it. They'll learn the "design sense" that Feathers keeps talking about.
Bob - I like your emphasis on micro decisions. There is something very powerful about the agile emphasis on very short feedback loops, during development, project managment, etc. I see lots of analogies in business, sports, personal health, finance, etc. The very good people make very fast small corrections, and make it look easy. For example, some people can stand on a ball, balancing with very little apparent effort. Whereas most people don't notice they need to make a correction until it needs to be a big correction. By then it is risky, desparate, and the odds are tough. I like this kata approach to learning to make the micro decisions. I look forward to hearing more about the elusive "design sense."
hi there,
i know it will be a poor question to u. still cant resist.i have done C as a whole but when it comes to solving a complex problem i lose all the clues.also i m not able to develop some application specific program. can u tell me some effective ways to get along with the problems.
many thnx for the response.
i know it will be a poor question to u. still cant resist.i have done C as a whole but when it comes to solving a complex problem i lose all the clues.also i m not able to develop some application specific program. can u tell me some effective ways to get along with the problems.
many thnx for the response.
Add Child Page to TheProgrammingDojo