This post is a summary of my impressions from the 3rd and last conference day of ØreDev 2009.
If you’re looking for write-ups of the other two days, go here:
Scott Hanselman, “Information Overload and Managing the Flow”
Scott is a real super hero when it comes to being efficient. He has been so efficient that Microsoft has swooped him up and turned him into a manager. He utilised this to the full in his talk when he said “I work for Microsoft” and showed a picture of the death star.
Scotts talk was about how you can handle the information flow and be efficient, doing things right. Of course, there is no point being efficient if your not effective, doing the right thing.
Scott covered the work of some prototypical gurus on becoming more effective, e.g. Stephen Covey’s 7 Habits and David Allen’s GTD (Getting Things Done). Covey prioritises using importance on one axis and urgency on the other, creating four quadrants. Allen talks about 4Ds: Do it, Delegate it, Defer it, and Drop it (I think they were). As Scott pointed out, very few things are really urgent. “Are the children on fire? No? Then it can wait.”
Scott talked about the psychic weight we put on ourself with our ToDo lists that grow longer and longer. What was once a pleasure to do can turn into a burden. Scott: “Tonight is the night! Let’s just push through the whole season of Prison Break. Be done with it!”. I can relate to that, having had half a season of 30Rock to look through for many months.
Here were some effectiveness/efficiency tips from Scott:
- Use bosses rule in you e-mail program (use filters to mark them especially).
- Don’t check email in morning. It may ruin your whole day.
- Conserve your keystrokes. Most e-mails can be ignored. The more e-mails you send, the more you get.
- Use Pomodoro Technique. Really focus for 25 minutes.Read aggregates of things that you like but don’t have time for.
- Use “43 Folders” (a GTD technique), one for each month and each day of the month. Put stuff in there for the day that you need it.
- Use tools like Evernote, Remember the milk, and LifeHacker.
Niclas Nilsson & Hans Brattberg, “The Pair Programming Show”
This session was completely different from anything else we saw in the conference. Hans and Niclas performed some pair programming theater scenes, complete with acting (well), props, graphics, and sound effects. We still mourn for poor Hans that was hit by that bus. Heart-breaking.
They started out showing the good stuff, how pair programming should look. We saw intense conversation, focus, common goals, and different roles.
After the proper version they showed some anti-pattern scenes:
- Professional Driver: Niclas acted wonderfully in how not to behave as the more experienced in a pair. I will never forget the content look on his face as his fingers were flying and he glanced over at Hans. Very funny! Instead, you must display patience, share equally, transfer knowledge, talk not show. Learning in cooperation must be the goal.
- Backseat driver: When one person of the pair leans back and is disconnected from the work it is less productive than sitting alone. Again, Niclas dominated the scene with annoying remarks and an air of absent-mindedness. For risky or expensive work you really need two people, think of surgeons and pilots. Pair work eliminates big mistakes. Pair also helps handle the pressure. It gives us courage. Another factor is that it gives transparency. No more “private backlogs” (you know, the stuff that people have in their note books to do on a better day).
- New companion: It is risky to be alone. More often than you think do you wander off in the wrong direction.
I really appreciated this session. Not because I didn’t know most of these things but because of the trouble they had gone to illustrate something that felt true for everyone. Well done!
Lasse Koskela, “Acceptance Test-Driven Development”
Lasse Koskela has written what is probably, up to now, the best book on TDD and ATDD. It was a pleasure to meet him. Lasse was also one of the guys in the big agile adoption project at Nokia Networks.
Lasse’s message was that ATDD is not (only) about verifying. It is about understanding things together. In his view, ATDD consists of 1. Validation (are we doing the right thing?) 2. Specification (how do we know?) 3. Verification (are we done?). He separates tests from checks (an idea from the contextual testing school), to illustrate that testing is more than checking.
ATDD always includes facilitation and is driven by examples. It does not necessarily have to be automated or performed before programming, but that is recommended and normally the case. ATDD is team activity. It has lower value without the business side and minimal value doing it alone.
My reflection is that maybe ATDD should find a better word than “test” the same way BDD has, instead of trying to turn the word “test” into “specification”? To most people, testing will always be just checking.
Lasse is a calm and assertive presenter. I was a bit disappointed about the models galore in this session. The lack of examples was striking (quite ironic in a session about driving work using examples…).
Cucumber, Aslak Hellesøy
Aslak Hellesøy is one of the real pioneers in BDD, having been an contributor of RSpec and creator of Cucumber. Both these tools are really top-of-the-line when it comes to BDD at this point in time, in my opinion.
Aslak explained briefly the motivation behind BDD. He meant that “TDD got the names wrong”. BDD involves the ubiquitous language. BDD involves customers. In BDD we work “outside-in”, meaning we start from the UI and drive the rest of the functionality from what is really needed.
My reflection: I believe BDD people perform a bit of a straw man on TDD, saying that it’s all unit testing and no customers. This is very much not true. ATDD or “customer tests” as they are called in XP have been a part of TDD all the time.
Anyhow, to do BDD we need to have a common understanding of what “done” means. One facet of “doneness” is that all test scenarios run. In BDD these are often called acceptance criteria and are formed using “Given – When – Then”. Note: “Thens” are always outputs from the system.
After this, Aslak went into the main topic: Cucumber. Cucumber is a “story runner”, meaning that you can write descriptions of features and acceptance criteria in a domain language and having that executed by the framework. Gherkin is the underlying language of Cucumber (the tool). It sports full I18N, which is critical for having a natural communication with customers.
Some Cucumber statistics from GitHub: 80 000 downloads, 180 contributors, 40 integrated tools, 1 550 followers on GitHub, 20 screen casts.
No tool talk is complete without a demo, in this case a RPN calculator. My colleague Måns commented at this time that mathematical examples may be convenient for the presenter, but they are irrelevant for most spectators. Hint: Choose your examples wisely.
Aslak showed some Cucumber goodness. Not everybody knows this but it is possible to have templates with tables beneath for sample values. Cucumber will run one example for each row in the table. This is inspired by FIT. A few things that were new to me were backgrounds, tagged hooks and tagged execution. Backgrounds are fixtures for a whole feature. Tagged hooks are used to decide which scenarios should get what part of the setup. Tagged execution is used to decide which scenario should be run, e.g. based on the current language.
One downside with the BDD tools compared to Fitnesse is the availability. Fitnesse tests are on a wiki page, meaning a lot of people may read, edit or even execute them. This helps pull the product owner into the team. When confronted with this Aslak said they were working on a web interface to see and run tests, but that it would not be open sourced. Ouch!
Kevlin Henney, “Modelling in the Age of Agility”
Kevlin Henney is a developer conference fixture and he is always entertaining and thought-provoking to listen to. For this talk, Kevlin had chosen to talk about modelling and how he thinks we should approach it in these agile times.
Often, he says, the perception of modelling is a problem. Models are not correct. Nor are they specifications. Models are abstractions from a point-of-view for a particular purpose. To create an abstraction we need to omit stuff. Not everything is equally important. One classical example: Underground maps.
The usefulness of a model is what is most important. Powerful question: What is the problem we are trying to solve? The basic usefulness lies in the “ing” of modell-ing, i.e. sharing and discussing different views. Modelling is exploration.
Some common model pitfalls: Poor model, Model not needed, Wrong model.
My thoughts when hearing about modelling is always to remember that the code is also a model – a very detailed model of reality. And hence, as a model, code can also be the common form we use when discussing and communicating solutions between developers.
That concludes my reporting from the sessions at ØreDev 2009. I will be posting some spin-off reflections on specific topics in the upcoming weeks. Thanks for reading!