This post is a summary of my impressions from the 2nd conference day of ØreDev 2009.
If you’re looking for write-ups of the other two days, go here:
Rebecca Wirfs-Brock, “Responsibility-Driven Design”
Rebecca Wirfs-Brock is one of the early though-leaders in object-orientation. Her book on RDD came out in 1990.
Rebecca’s keynote speech was a run-through of different ideas about OO design, from the early days up to today. Maybe it was a little bit too basic and sententious for my taste. She described the early thinking with CRC cards (Class, Responsibility, Collaboration) and how those expermints evolved into RDD. In RDD you describe any role from its stereotype. The stereotypes are: Information holder, Structurer, Interfacer, Service provider, Coordinator, and Controller.
Rebecca tried to describe the greatness about emergent design when using TDD/BDD but did not quite succeed. I got the feeling she had only read about it (I may be wrong). For example, she failed to see where design happened in TDD (she said “it seems to happen between the lines”). Or was it because she had totally missed the refactoring step?
The most interesting parts of this talk came at the end, where Rebecca alluded to the work of Christopher Alexander, the renegade architect from which the design patterns movement emerged. He had tried to identify properties of things that have life, e.g. “strong centers” and “boundaries”. He called this liveable design. The idea, if I understood it correctly, is that no matter which design methods we use, we should always strive to create “liveable software”, i.e. software whose design display signs of life.
Dan North, Neal Ford, Stuart Halloway, et al, “Making the sausage”
After RDD I went to an impromptu session that replaced a late programme cancellation. I had heard that Dan North, Stu Halloway and some other guys sat up late the night before, trying to come up with the design for a new BDD tool for Clojure. On this session they would present a super-early draft of what they had. I mean, BDD and Clojure! Any cooler than this and it would be Day After Tomorrow. Who could resist going!?
After an introduction by Dan and Neal, the session mostly consisted of Stu showing their ideas in Emacs. Obviously, they had written a whole bunch of specs they would like to able to write, but for which there was only limited support so far.
It was interesting to hear about some of their guiding design principles. Dan was, predictably, very adamant about “getting the names right”. Stu thought it was important to use idiomatic Clojure. They wanted to support having tables (like in Fit) and use “bubble words” like “should” and “it” (they are called bubble words because they don’t actually do anything, they just bubble away). Stu wanted to utilise the support for metadata that already exists in Clojure.
Currently, it works through the Clojure reader, using reader macros to convert from the specs to clojure.test code. They were quite unsure if this would be the final design though.
One reflection I had afterwards was that there is a small, but inherent, conflict between the goals of BDD and FP. BDD wants specs to sound like natural language; “<result> should == <expected>”, but idiomatic FP is more verb-noun; “== <result> <expected>”.
Scott Bellware, “Test-Driven Web UI Development”
Scott Bellware, one of the founders of the ALT.NET movement and BDD for .NET guy had a pretty confused session on test-driving a Web UI. It was really hard to understand where he was going with and he never did make it to the finish line.
Scotts idea, if I understood it correctly, was to start by using Selenium IDE to record the interactions with a web GUI. Translate the generated code into Ruby. Then, move this code into RSpec. But instead of stopping there, the developer should continue, by creating abstraction in the “contextual language” (domain language) to make it easier to add further tests. However, Scott never managed to get it working because of an FF quirk when offline. Also, he had a lot of troubles using MacOS X Exposé (probably due to the dual screen screen). This gave the whole talk an unfinished feel.
Scott was also questioned and disturbed by loud-mouth test guru James Bach in the back, asking why developers insist on automating everything (in a rather derogatory tone-of-voice)? My reflection is that I wonder if James has ever participated on an agile team? How are they supposed to do regression testing without automation if you deliver to production once a week? Or what about those who deliver almost every day? Or 50 times a day that some teams do? There is clearly a large gulf here between the leading testers and the leading BDDers. And it’s a shame! I really like how the contextual school of testing (which James founded) fits into agile work perfectly.
I think I liked what Scott was trying to do. However, I have one caveat: Don’t call it TDD when the tests are generated by a recorder. That’s just plain wrong.
Tyler Jennings, “Strangling a Java Web App with Rails”
The title of this talk was truly electrifying. I guess that’s what a lot of us Java/Ruby guys will be doing this coming decade (a joke with maybe a bit of truth in it). However, I managed to miss the first half of the talk. Secondly, I think Jennings had too much material; the word “strangling” popped up the first time after 52 minutes (of the 50 min talk…).
However, I managed to understand that the basic idea is to hook in a servlet filter after the Java application and handle the call if it was not handled by Java. His application used JRuby-Rack, an adapter for the Java servlet engine into, for example, Rails. That way, pieces could be first implemented in Rails and then removed from Java. Of course, JRuby was used from Ruby to call into to the Java app if the need arose.
Michael Samarin, “Making Web Applications for iPhone”
This talk was a disappointment as it basically turned into a commercial for Dashcode, Apples RAD tool for web applications. Samarin did show some cool stuff though. He quickly and easily created an iPhone web app that controlled a video show on his MacBook. Tools he used were Dashcode, NetBeans, Quicktime, AppleScript, and XMPP.
If you want to quickly get an iPhone web app up and running you really should have a look at Dashcode. There is no need for approval from AppStore and with Safari you can make it look a lot like a real app.
Adam Skogman & Emil Eifrem, “NoSQL”
This session was packed. I had to stand at the end of the room. Apparently, NoSQL databases are hot hot hot. And luckily, we got a really good presentation on the topic from the two well-rehearsed and knowledgeable speakers.
NoSQL databases were created to handle two major problems with SQL databases: Scalability when the amount of data is huge, and flexibility, when the domain is complex. They come in four different flavours: Key-value stores, Big table, Document, and Graph.
Key-value stores are most suitable for scalability. They are essentially “bit buckets”. Some notable contenders are Oracle’s Berkeley DB and LinkedIn’s Voldemort
Big table is a Google invention. The basic idea is that you can have any column for any row and instead of creating a lot of tables you simple have a lot of columns. And I mean a lot! There could be hundreds of thousands of columns. Google App Engine and Apache Cassandra are two candidates here.
Document databases store “documents”, e.g. a JSON structure, to handle the semi-structured character of most worldly things. Couch DB and RIAK are two popular examples.
Graph databases model the world in nodes with relationships, creating a graph. Attributes may be placed on both nodes and relations. These are mostly aimed at the flexibility problem (not scalability). Graph DBs have “whiteboard friendliness”, meaning that’s normally how people model their world. Look into Neo4J or Allegrograph, for example.
Since very few have the scalability problems of, say, Amazon or Google, in a poll most people predictably were interested in Document and Graph databases.
To end it all the speakers were very clear that they were not being confrontational against relational DBMSs. NoSQL is pronounced “Not only SQL”. Believe it if you will…
Gojko Adzic, “Specification Workshops”
Gojko Adzic is the author of two books on how to bridge the communications gap between developers and customers. He is a funny, no-nonsense guy. He told a very entertaining story about how he could not get a bank account when he moved to the US because he was not registered as a voter. In the US people really believe the content of their DBs, he said. After a lengthy discussion he was allowed to move on in the process, but now it was blocked because he had not payed taxes last year. He tried explaining that he had migrated to the US only two days ago and had payed tax in Serbia. However, they honestly believed that their databases contained all information. Gojko answered: “This is ridiculous! There is no way. The two government computers in Serbia are busy playing Mine Sweeper”.
Acceptance testing is based on the idea that better customer acceptance can be achieved if we discuss and define examples of how it is supposed to work before we design our solution. Only unit tests will not do, since customers simply don’t understand them. Furthermore, they often hide this because they don’t want to sound stupid. What may sound obvious to me is not obvious to you.
Two good tips around requirements from Gojko: 1. Ask “why” more often. This will help you understand the true need. 2. Never accept solutions from customers. Instead, say: “What do you need?”.
About the customer/product owner I think Gojko is right on the money. He said that “know-it-all customers” are as mythical as dragons. Customer is a role. Understanding the true needs should be a team effort, a collaboration between those who know the need and those who can fulfil it.
A “Specification workshop” is a meeting where you discuss needs, requirements, and examples for upcoming development. Gojko thought that name often worked better with busy people than “Example-writing workshop”, which sounds unimportant to them.
Here were Gojko’s advice for these types of workshops:
- Collaborate on specifications.
- Challenge requirements.
- Discuss examples.
- Involve the whole team.
- Schedule meetings well in advance (for busy people).
My reflection after this session was that it is certainly true that customers don’t know what is needed. However, I think Gojko’s solution could be improved. His solution was this: Let the team work with the customer. But that doesn’t really solve the problem, does it? The customer doesn’t know much more from this. The problem is this: Nobody really knows! It is software we’re talking about. You could ask users but they won’t know either. They feel the pain directly, but often lack the overview. Or know what’s possible. However, there are professionals out there that know how to talk to users and distill their needs. They are called user experience (UX) specialists and are experts on user research and user-centered design (UCD). I believe they have a really important role to play if we want to be effective, not only efficient, with agile methods.
Robert Sabourin, “Out of the Frying Pan and Into the Fire – Efficiency in Scrum”
The day ended with a keynote by Robert Sabourin, a very loud Canadian methods expert. He talked about different ways that people get methodology wrong. I didn’t find it very amusing, I am sorry to say.
One nugget of coaching though: As a coach, start by asking the staff for recent stories when thing went wrong or went extremely well. For each story, drill down in full detail. This may help you find where the problems and strengths lie.