We’re knowledge workers. What we deliver is a direct result of the perception of the problems we are exposed to. Yet, there are a lot of people trying to escape from the responsibilities our job requires.

Some of these responsibilities include:

• Design decisions (TDD)
• Impact of our changes on the rest of the project (CI)
• Sharing knowledge and the code where it’s represented (PP/Standards)
• Making sure what is delivered has any value (Reviews/Frequent Releases)

In this context there’s no room for peonage. Our job is basically to make decisions all the time and being agile is about making sure we can answer (and answer well!) for our actions.

That’s why I agree with Patrick Kua’s post about this topic. We have to understand the business problems and the possible solutions. We have to help each other to build something. We can’t stop learning. We can’t  be limited by our normal role. And most important: we have to care.

My idea with this group is also help people interested in running other dojos in the city. So far I know Danilo from ThoughtWorks and the guys from YouDevise who are doing that, and I hope to see more next year.

The first session will be on 1st of December and the idea is to have one session every 2 weeks starting in January. All the sessions are free but be aware that some sessions may have limited number of people.

Can you imagine how hard it would be trying to develop a software without seeing it? Well, this guy not only took the challenge but he wrote about how he actually accomplishes that.

First of all, he needs to hear all the code. He uses a speech software with some tweaks to make PHP keywords sound simpler in Portuguese. He also has to be strict about coding standards. A brace in the wrong position and he may get lost. So he not only isolates them in a new line but also comments the context it’s opening or closing.

Indentation is not important for him and in fact it make harder to know where the cursor is. For him reading other people’s code becomes a bigger problem too. But apart from that, he doesn’t complain and goes on writing software without major problems. He teach PHP classes too (and it’s probably being invited to do motivational talks for programmers after that article).

After reading that I gave a second thought about my problems using TextMate. It’s relatively easy to write a new bundle, or even switch the text editor. I can even write a new text editor from scratch if I really feel like it. Writing code is easy. Trust me.

The aim of this site is to contain a growing collection of software problems well-suited for the TDD-beginner to learn Test-Driven Development through problem solving.

Today the site contains 20 different “real-life” problems, which is probably enough to keep anyone busy for a long time. And since it was announced in the testdrivendevelopment list only a few days ago, it’s very likely the list will keep growing.

Enjoy!

Setting up

You don’t need much more than a place with one computer connected to a projector and enough sits for people attending. A timer to keep track of the pair rotation and a white board or flip chart to discuss the problem are also very useful.

If providing foods and drinks is not in the plan, at least don’t forget to have enough water for people in the room. Breaks are acceptable, but the idea is to get people focused most of the time.

Introducing the dojo to new people

In my experience, the dojo is not suitable for everyone. Not that you have to be special to be part of it. Not at all.

The problem is that people are used to learn in different ways. Some don’t like to slow down and see things they already know being done step by step. Those will become inpatient and probably get in the way of those seeing things for the first time. In other cases, people are so used to learn by themselves that is hard to share this process with other people. There’s also people who will simply find the problem too easy/hard to solve and therefore useless for them.

My suggestion in this case is start with people who already know how the dojo works. Even if it takes doing a small presentation to explain it. Show that the point is not the problem itself. The point is deliberate practice. If people accept that before the meeting starts it should flow way easier.

The right style and size

The number of people is also important. Is very hard to run a randori with more then 10 people. Specially if they are new to the dojo. People approach a problem in different ways and it may become hard to listen to everyone’s opinion in this case.

In the other hand a kata can be done with more people at the same time. This approach requires some effort to prepare and practice the solution for a challenge, but may help to introduce the idea of the dojo before getting everyone involved in the coding.

Choosing the coding challenge

There are load of sources for problems out there. The guys from Dojo São Paulo have a list in their wiki, but in principle any well known problem is okay. I really like something like Mine Sweeper to get people started, and then let them help to choose new problems based on that first experience.

Remember that starting with a completely new language is a good idea only if people do their homework and try to learn the basics before the meeting. Otherwise the meeting will be only for reading documentation instead of coding.

Don’t forget the retrospective!

The dojo is a place for continuous improvement, and the retrospectives are essential to achieve that. It’s normal to have some problems during the meetings, but there’s no excuse to discuss them and do things better next time. For the good things is also interesting to discuss to acknowledge what’s working and try to keep them.

Try to get everyone’s feedback. If people are not motivated to talk, well, that’s the first problem to be solved.

Now that you’ve started…

… It’s time to merge with the software community around you. It’s easy to find more people to attend to the meetings. Simply invite and they will come. I try to attend all the dojos I’m invited because I know how much I learn every time I see other people programming in front of me. For the same reason I’d like to always have new people in my dojos.

I hope to be inviting people through here my dojos soon. At the meantime, I’d be happy to help anyone interested in starting a dojo. In this case, just let me know.

If you want to learn more about the practices I mentioned,  here are some useful links:

• The Page Object design pattern in details
• How to use Selenium Grid on the Amazon EC2
• Configuring tests to run in parallel using TestNG

Craftsmanship over Crap.

Although most of us can identify with that statement, it’s probably not easy to sell the idea put that way. But now he rephrased it to:

Craftsmanship over Execution.

I confess the first time a thought about software development being a craft was in a Joel Spolsky’s article disagreeing with the use of this term. In the post he suggests creating software is more related to design than craftsmanship, but he reinforces the idea of software not being simple execution.

After working with a lot of different people, it’s easy to distinguish who think about software as being craftsmanship or mere execution. And undoubtedly the best developers and consequently the best software always come from the first category. They care about what they’re producing, are passionate about it and never stop learning. They want to become master craftsmen and know it depends only on their own attitude.

The question is: should the Agile manifesto include that statement? Personally I don’t believe so. The “Individual and Interaction over processes and tools” part already implies that. Focus more in processes and you’ll end up caring more about execution. Value people and the craftsmanship aspect of building software will become natural.

To run a coding dojo people don’t need much more than a computer and a projector. Paying for the pizza and some beers for the end of the meetings is not expensive either, and is surely welcome. But if the company is really cool, some dojos can take place during work time to get more developers involved. Note that none of those items take lots of money nor is too complicated. The only things needed are some engaged developers and good sense of the company to invest in their professionals.

2. Stimulates social and self-organization skills

Many developers have some hard time when talking in public, exposing their ideas or collaborate with other people. Others have problems to self-organize, work in a team or even lead. When does a company invest on those kind of skills of a developer? Rarely. The dojo is a great start for those people, and even who doesn’t have any of these difficulties will have a chance to exercise their skills and explore points which may need some improvement.

3. Is good publicity for the company

If the company took the first step and the developers are already comfortable running a dojo, why not open the doors for the public? The company name will become associated with the agile principles behind the the coding dojo and developers won’t have to leave the company to network. Better, if everything goes well the company won’t have to publish ads to get new developers since the potential candidates will be part of the company’s routine.

4. Helps developers to be active in the community

Discussing the techniques applied in the dojos can be a good incentive for some developers to participate more in the software development community. It can also be a first step help some open source projects, publish articles or participate in conferences.

5. Breaks the routine

Code something different from the daily projects, using other languages, tools and techniques, with other people and in a more relaxed environment may be very stimulating.

So, do you need more reasons?

Carlos Brando release the first book on RoR 2.1. More information and download here.

• Estimate your requirements using a size metric.
• Agree on the concept of done.
• Define a timebox size.

Then we just need the formula:

Velocity = Points done / Timebox