InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Coding Dojos to Master the Art of Development

Posted by Amr Elssamadisy on Sep 01, 2007

Sections
Process & Practices
Topics
Collaboration ,
Community ,
Agile
Tags
Continuous Improvement ,
Best Practices

Coding Dojos are meeting places where developers can go to practice coding together and improve their development skills in a relaxed and enjoyable setting. Emily Bache and others have started to document dojos on a wiki where the public can go to get started.

Dave Thomas introduced the code kata and documented twenty one different katas that can be used to hone our programming skills. His reasoning behind this approach to learning was:

How do you get to be a great musician? It helps to know the theory, and to understand the mechanics of your instrument. It helps to have talent. But ultimately, greatness comes practicing; applying the theory over and over again, using feedback to get better every time.

How do you get to be an All-Star sports person? Obviously fitness and talent help. But the great athletes spend hours and hours every day, practicing.

But in the software industry we take developers trained in the theory and throw them straight in to the deep-end, working on a project. It’s like taking a group of fit kids and telling them that they have four quarters to beat the Redskins (hey, we manage by objectives, right?). In software we do our practicing on the job, and that’s why we make mistakes on the job. We need to find ways of splitting the practice from the profession. We need practice sessions.

Coding dojos are places where groups of people come together to practice katas together. When InfoQ asked Emily Bache about the intended audience for a coding dojo she responded:

I think anyone who wants to improve their coding skills, particularly in the area of Test Driven Development, should consider going along to one. The idea is not really new, there have been user groups and study circles meeting to share experience for years, and this is really a new angle on the same idea. I was a member of a group studying design patterns a few years ago, and the dojo is really a new brandname for an old idea. A bunch of people who all want to improve their skills, learn from one another, and have fun doing it.
The premise behind this technique is that deliberate practice, not pure talent, creates expertise. By going over the same small problems again and again you find yourself having small 'aha!' moments that further your design and coding ability. As Uncle Bob put it after attending a presentation by Laurent Bossavit on coding dojo:
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.
So, coding katas can be performed individually or in groups to hone our development skills. Coding dojos are places where developers meet in a fun and relaxing environment to practice together. And all of this requires that we take extra time, after our 9-to-5 to improve our development skills.
  • This article is part of a featured topic series on Agile
Martial arts comparison by Rickard Öberg Posted
Re: Martial arts comparison by ryan martin Posted
Re: Martial arts comparison by Rickard Öberg Posted
Re: Martial arts comparison by Keith Barlow Posted
Variations by Greg Akins Posted
  1. Back to top

    Martial arts comparison

    by Rickard Öberg

    The comparison between software development and martial arts can be very useful. There are a number of concepts in MA that have counterparts in software development.

    Techniques in MA would be the counterpart of programming languages: coherent atoms that can be combined using specific rules.

    But I would probably compare kata more to design patterns, as kata usually are very strict in how they should be applied, just like design patterns. What is described as kata in the article sounds more like randori, that is sparring within some specified limits, and where kata is to be applied. Free randori is like street-fighting (i.e. martial but without the art), and programming without design patterns usually ends up in spaghetti code. And when randori feels like kata, and kata feels like randori, then your technique is probably pretty good, so perhaps the line between the two is vague :-)

    Another useful comparison is that of Shu-Ha-Ri, i.e. the progression of understanding of MA. In the initial Shu-phase ("Protection") the aim is to learn the technique as well as possible. Learning the language, and learning what the design patterns look like. The goal is to be able to repeat the techniques with perfect movement.

    In the Ha-phase ("Destruction") you learn how to apply the language and patterns on real situations, and what their core components are. In this phase you also learn to remove any unnecessary movement, keeping only what is important. This is similar in software development, where you will want to learn how to achieve minimalism and yet get the job done without creating simplistic designs that cannot adapt to new situations.

    In the Ri-phase ("Distancing") you learn how to put your own personal style on the expression of Martial Arts. Usually only other people who have achieved Ri-stage can still see the individual kata during a performance, as the movement has been perfected and minimized. In MA this is a big problem, as it is far too common that Shu-students try to learn MA by mimicking Ri-masters, thus producing the wrong movement as there is no understanding of what is supposed to happen. The result is disastrous, and the same can be said in software development. SOA is perhaps the best example right now, where experts on the topic say one thing ("use web services"), and beginners without the necessary experience filter and translate it into their own faulty vocabulary, producing nothing but garbage as a result("@WebService"). In both MA and software development, this situation can be quite painful to watch. It is perhaps worst when supposedly Ri-masters fall victim to this disease.

    Another common problem between MA and software development is that of ranking. In some schools having a black belt only means that you know the teacher well, or that you have paid some amount of money. In software development sometimes the proclamation of being a black-belter means nothing more than the individuals own belief that it is so. But as with the problem outlined above the end result is usually disastrous, leading to opinions about this and that which have no foundation. In proper schools each rank has a specific meaning, preferably related to not only techniques and kata, but also to the Shu-Ha-Ri progression. In such a context a rank can actually have a useful meaning and purpose. In software development this is rarely the case I have noticed.

    One saying I've heard often in the dojo is the idea that "practice makes perfect" is incorrect, and that it should be "perfect practice makes perfect". In both MA and software development you will often find people who have practiced for a very very long time, and yet still fail to grasp fundamentals of technique and kata. Quite probably this is due to imperfect practice. So if you practice, make sure it is done with perfection, or not at all. :-)

    Lastly, the importance of Saho ("etiqeutte") in the Dojo is considered vital. Sadly this is not the case in software development circles, but it probably should be. Respect and humbleness where applicable is a good thing I think.

  2. Back to top

    Variations

    by Greg Akins

    At the Pittsburgh Coding Dojo (www.pghcodingdojo.org) we've moved from some of the "traditional" katas. It seems that this has added to the diversity of our membership.

    Rather than attracting only the XP "crowd", and focusing on TDD and pair programming, we spend more time simply exploring algorithms, data structures and puzzles.

    Folks can program in pairs, or not. And can use any language they would like.

    Whether following strict "Kata" like exercises, or simply spending time programming with other passionate developers, our members seem to be attracted to the opportunity to learn to program better.

    The CodingDojo.org Wiki will hopefully provide a useful resource for exploring different practices that can help these small groups become more mature and to serve a greater community of developers.

    Greg Akins
    Organizer, Pittsburgh Coding Dojo
    pghcodingdojo.org
    groups.yahoo.com/group/pghcodingdojo

  3. Back to top

    Re: Martial arts comparison

    by ryan martin

    Wow, way over analyzed IMO. You took a basic metaphor and
    added unnecessary complexity.

  4. Back to top

    Re: Martial arts comparison

    by Rickard Öberg

    Wow, way over analyzed IMO. You took a basic metaphor and
    added unnecessary complexity.

    Perhaps. But I have found that the comparisons go way beyond just using the words and "Dojo" and "Kata", so to me where you see complexity I see clarity. By understanding more about MA I have learnt more about software development, and vice versa. But trying to explain this to others is perhaps a futile exercise. Some things just have to be learned the hard way it seems.

  5. Back to top

    Re: Martial arts comparison

    by Keith Barlow

    I think he is right. I am not an overly experienced developer but I have found that as I have gained experience, I start to see things from new angles and perspectives and as my clarity and comprehension of the material progress, I am better able to deal with problems is more effective manners. I cannot speak for the martial arts analogy as I am not a martial artist, but I can comprehend his perspective and the ability to express these concepts in such an elaborate way definitely portrays a deeper understanding of the material. So too often, people accept the simple solution over the right one.

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.