Code Kata August

[Audrey R. Troutt]

Thank you to Andre, Bonnie, Adam, Aaron and Sebastian for coming out to Code Kata night at the Math Forum! This was an experimental kata night in that we were trying out architectural katas for the first time.

In the beginning we went through a summary of the basic elements of architecture: communication/distribution, presentation/interaction, state management, processing, resource management and tools. For this we followed the slides that Ted Neward provided especially for this event and exercise. The idea is, roughly, that when you are designing the architecture of a system you have to consider each of these elements. I think we can all agree that one way or another requirements inform your technological choices. Asking questions about the system with regard to each of these elements can make it more likely that you don't miss support for a critical aspect of the system. Here are a few examples:

• Communication/Distribution: In what format does data travel? JSON? XML? Over what medium? http? filesystem?
• Presentation: What sort of perspectives in to the system do you need? do you need an admin console?
• State Management: Does the state need to be persisted across different sessions?
• Processing: Does processing need to be transactional?

Then we made two groups, each randomly selected a kata and spent 25 minutes trying to come up with a suitable architecture to meet the requirements. At the end of the time each group presented their proposal for 3 minutes and fielded 2 minutes of Q and A from me and the other group. I played the role of the customer/game master, answering clarifyng questions about the application.

I think it is fair to say that these exercises were hard. One of the exercises was to build a MMORPG. None of us had any experience building similar systems, so there were a lot of open questions about what was possible and how it could be done. I was probably not the best customer for this project either, since I have hardly seen a MMORPG before, let alone thought about how I would want one to work. Even if you are familiar with the domain and know about some of the relevant technology, it is still hard to cover all of the architectural bases in 25 minutes.

In the retrospective that followed the question came up, what are these exercises good for? Would this exercise really be valuable to the customer? Andre voiced his skepticism of architecture as a subject because that is not how he would ever work with a customer. As agile-minded folks, we prefer to see the architecture emerge as you are iterating and building the system with your customer. I don't think these exercises are really intended as practice for starting a project with a customer, although I may have set that up by calling myself the customer at the beginning of the exercise and saying that I would decide if I wanted to buy the system at the end. I like these exercises because it is an opportunity to wonder about how things work, and it piques my curiosity to go learn about technology that I haven't had a chance to use at work before (or yet?).

One benefit that we saw of these exercises is that they could get the whole team involved in design. Sebastian told us that his team actually does something similar on a regular basis. Pairs will take a card off the wall, think about how they are going to do it and "pre-sell" the approach to at least on the other pair (more for major changes). When the story is done they can present the result and the rest of the team has a chance to say "hey--that's not what you sold me!" which can help to reveal what the pair learned while they were building it. We also discussed ways of displaying architecture or the state of the system in the team area. One idea was modular printouts on the wall, legos or knex. All of these could be kept up to date as things changed. Sebastian once used the printouts as a progress chart, checking off parts of the system as they were completed.

All in all this was a fun kata night and I look forward to the next one. Many thanks to Ted Neward of Neward & Associates http://tedneward.com for letting us use his slides and architectural katas for our kata night.

[Sebastian Hermida]

Audrey, as I reread your post, I am thinking that the work that we (Aaron and I) showed to the group was targeted to our peers (programmers, architects) but definitely not customers.

Our talk was fairly technical. We even mentioned the pub-sub pattern and we showed you a basic domain diagram. I don't think I would show these artifacts to a potential customer. I will tell how much the app that we are building will help them kick a$$. How much profit/business they will make...The implementation is up to us, programmers.

Maybe clarifying the game master role next time could help sell our design to the right audience.

Practice will make this kata perfect!

[Jon Kern]

damn, sorry i missed it! had to go to the high school with our girls.

BTW: for projects that I sense could benefit from a highly-novel architecture, I generally have a technical spike to explore architecture in more detail. I usually don't want the architecture to emerge in these cases, as it could be very disruptive. For run-of-the-mill projects just roll out the "usual." It is a judgement call on how best to spin up an architecture for a project. (I certainly want to avoid 5 developers implementing 5 different opinions on how to do the same thing.)

[Sebastian Hermida]

Fantastic summary! Can't wait for the next one!