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
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.
Audrey,
ReplyDeleteRegarding the katas, I am curious if you have done other code katas and what you thought of them. At our firm we are just dipping our toes into katas and my initial feeling is they need to be simple exercises in order to allow someone to fully execute them in < 1 hour. Re: architecture katas, I think it comes down to what you think architecture is, but as a kata I want to find something small.
For example, one I have been thinking of trying is: Build an exception handler that supports user-friendly error messages while providing the ability to see technical details such as stack trace. I think this will help developers understand the intricacies of error handling, which is one of those things that can drive a system to total chaos.
Also, quick note. The tedneward.com link is broken. It is include the subsequent "for".
I have also done code katas from http://codekata.pragprog.com/ and I really like them. Not the exercises in particular, but the opportunity to practice. I agree that the simpler the problem the better so that you can focus on the code techniques you are trying to practice and not the domain, but it is also valuable to pick a problem that we can't solve in the time allotted. This reinforces the idea that you are just practicing a technique. Also, we throw away our code at the end.
ReplyDeleteArchitecture katas are an experiment; we so rarely get a chance to practice thinking about the system on that level or thinking about systems that are far outside of our familiar domains. How would you build a MMORPG from scratch? I hadn't really thought about it before, and the ideas and questions that came up while we were discussing it were valuable to me even thought I will probably never build one. It's a big problem and we didn't solve it, but we practiced asking the questions that we needed to in order to come up with a workable architecture to solve it.
I really like your exception handler idea! I would like to think about how many different ways you can do that. And to think about how it would be different on a webapp, on a desktop app, on a mobile app. That exercise would be somewhere between the code kata and the architecture kata. I like it.
Thanks for the heads up on the link. It is fixed now.