A few years back, I ran a public course in Düsseldorf, Germany. While looking through my options for one of the evenings, I noticed a public Coding Dojo run by the Softwarkskammer group there and decided to have some coding fun in the evening. During the dojo, I had an experience with one of the attendees that I keep on sharing every now and then.

I think I wrote up on this a while ago. Since I keep on referring to that experience, I thought maybe a reflection on what I think happened a few years later, might be helpful.

The setup

Upon arriving at the venue, there were five or six other people with me. The host, Georg Berky if I recall correctly, had invited us to do the Mars Rover kata. Georg explained the idea of a coding dojo and how we would be working as an ensemble that evening.

During a quick round of introductions, we introduced ourselves to each other as most of the folks there did not know each other. One of the participants introduced himself as an architect at his current employer. I remember me thinking: “Oh, how awesome we attract also some architects with these Coding Dojos, maybe making a real change in their organization.” Oh boy, was there a surprise going to come up on me.

We decided to go with Java as programming language to solve the Mars Rover problem after Georg introduced the problem we should solve, and we sketched a couple of worthwhile test ideas to get us started.

The beginning

We had the first pair start us off. I don’t recall whether the self-identified architect was in that group or not. I just recall him during the first few tests lamenting on how all this test-driven development was not worth the time, thinking harder about the design, and then just writing it down, was the way to go, and so on. I guess you might have heard some of these arguments over the years.

Anyways, the timer rang, the pair rotated, another person joined, and we continued to make some progress despite the side comments from the architect person. After 30 minutes or so, we had come up with two different classes to solve the kata. I don’t recall how we named those two classes and what their responsibilities were. I just recall how I noticed something curious. One method in one class was calling lots of functions on an instance of the other class. That raised my awareness, and when the next test was made to pass, we even added another call to that other class to that function.

I raised my opinion that the behavior we put on that one class really wanted to be part of that other class instead, and we should refactor the existing code to move that function there. In my memories, the architect blurted out how that would not have happened if we had spent some time on the design up-front, and the like.

The refactoring

We had a brief discussion about how to conduct that refactoring. The person on the keyboard tried to use the automated refactoring support in the IDE, but the IDE refused to do it since it considered the move unsafe. When the group was close to continuing without the refactoring, I said I might know a way to do the movement in a series of steps, and offered to jump ahead on the queue and show them how I would tackle it. The group agreed to put me on the keyboard.

I don’t recall the exact steps I took after all these years. I created a new function on the other class and moved created a new method on the first class that was delegating to the other class. Then I slowly moved over some of the functionality one piece at a time. At a certain point the architect blurted out how I had created a cyclic dependency between the two classes with all my steps now, and how that was bad and had we thought about the problem to solve more intensely in the beginning, we would be done by now.

Then I pressed to key combination for “Inline method” in that IDE, the old function on the first class was gone, all behavior was now on the other class, and the cyclic dependency was gone as well.

Silence.

“How did you do that?” was the next question raised by the architect. I showed him what I had done, and he seemed pretty surprised.

The takeaway

Different organizations have different career expectations. “Architect” in one organization can mean totally different things than in another organization, “tester” in one company can be totally different from a tester in another.

Most of my recommendations were highly motivated by the books I read over the years, probably the classic Gang of Four Design Patterns, Refactoring, Refactoring to Patterns, and Growing Object-oriented Software – Guided by tests. When I realized that the “architect” did not know about one of the most basic refactorings available in a modern IDE, I left that evening with the sense, that he may not have known much until that point. Unfortunately, those particular knowledge gaps led him to believe that his thinking was the more righteous one.

Today, I think, from his frame of mind he was correct. And we were correct from our frame of mind as well. It turned out as a happy surprise that we were able to learn about our different frames during that coding dojo.

And it intensified my belief that we’re merely at the start of teaching programmers about how best to work in a modern, agile working environment. Today, I think we have not much progressed, unfortunately, but we’re steadily continuing to do so, and fight crappy code along the way. Bring it on!