Archive

agile

RSpec book in beta

April 24, 2009
agile, bdd, programming, rspec, ruby, software, tdd, writing
5 Comments

It’s finally happening – I’m writing a book! Well ok, the remarkable David Chelimsky is writing a book. It’s called Behaviour Driven Development with RSpec, Cucumber and Friends and myself and a few other folks are contributing in varying degrees. The book is already in beta, which means you can buy the PDF now from the Pragmatic Press and you’ll get the print version as soon as it’s ready – and still get change out of $50, which can’t be bad.

The folks at the Pragmatic Press have been brilliant – especially the ever-patient Jackie Carter – and my second chapter will hopefully be in the next beta (or if not, definitely the one after that). It’s also surprisingly satisfying to be writing in vim rather than Microsoft Word!

Well, that’s enough for now. With any luck I’ll be back blogging a bit more frequently. Next up, learning about learning, thinking about thinking and why we are so crap at estimating.

JAOO Australia

April 24, 2009
agile, architecture, bdd, events, talks, tdd
4 Comments

A friend of mine has a Far Side desk calendar that he describes it as a barometer for how busy he is. Some days he finds himself tearing off a whole bunch of pages because he’s been too busy or distracted to tear one off each day.

I noticed a couple of weeks ago that I haven’t blogged anything for over six months. It’s been hectic. I’m planning to be blogging more over the coming weeks and months. I’ve got a ton of things to write up, ranging from planning and estimation – it’s no wonder we are useless at it – we don’t even know where to start!, to architecture – why you wouldn’t want to go on a date with Maven, by way of build and release engineering – why Ivy means Ant is still the king of cool.

JAOO Australia

I’m in Sydney at the moment where I’ll be speaking at JAOO Australia which is in a couple of weeks time. It’s like a pocket-sized, portable version of the European JAOO conference. In fact it is two conferences, one in Sydney (May 5-8) and one in Brisbane (May 11-14). There are two days of tutorials and two days of conference proper, and it looks like it’s going to be great fun. Both conferences are small enough (a few hundred people) that there will be ample opportunity to hang out with speakers and ask the questions you really want answered. And buy them beer.

I’ll be Pimping my Architecture and doing tutorials on BDD (principles and methodology) and TDD in Java (technical workshop), the latter with the lovely Erik Doernenburg.

If you can get to either city on those dates I would highly recommend it. As of writing neither event has sold out so there is still time. JAOO is one of the best geek conferences I know, with a great mix of technology (languages and frameworks), methodology (with an Agile flavour), architecture (from cloud to iphone) and soft stuff (Your brain is deceiving you. Yes you. Even though you know it is!)

The End of Endotesting?

September 14, 2008
agile, jmock, mockito, mocks, programming, software, tdd, testing
15 Comments

…or why Mockito is my new friend.

So what’s endotesting?

The pioneers of the technique we now know as mocking presented a paper at the XP 2000 conference, where they first introduced the idea to a wider audience. They prefaced it with the quote:

bq. “Once,” said the Mock Turtle at last, with a deep sigh, “I was a real Turtle.”

The Lewis Carroll reference appeals to me because I often cite Humpty Dumpty as the real creator of behaviour-driven development:

bq. “When I use a word, ” said Humpty Dumpty in a rather scornful tone, “it means just what I choose it to mean, neither more nor less.”

These folks – Tim Mackinnon, Steve Freeman and Philip Craig – realised that you could drop in a fake instance of an object that you could get to “fail fast” if it received a method call it wasn’t expecting:

bq. We propose a technique called Mock Objects in which we replace domain code with dummy
implementations that emulate real code. These Mock Objects are passed to the target domain
code which they test from inside, hence the term Endo-Testing.

This approach – endotesting – led to the creation of a number of open source frameworks, most notably JMock (written by Tim and Steve among others) and EasyMock. The basic premise of these frameworks was to make it easy to create a mock object and prime it with a number of expectations. (Your makeCheese method will be called with the parameter @”brie”@. When this happens, return the value BRIE.)

Having set up a mock object with its expectations, you wire it up into a bunch of objects and then poke the outermost object. If all goes well you can interrogate your mock and it will tell you its makeCheese method was called. If it doesn’t go well – well that’s when the magic happens. If you call an unexpected method on a mock it will fail during the test, giving you a stack trace from exactly where the unexpected method call happens. You don’t have to start rummaging through the call sequence trying to work out where it all went wrong, and your test doesn’t carry on running after the unexpected method call to produce a bogus result that doesn’t make any sense.

How we use mocks

Now if you are wiring together a complex group of objects to do something, endotesting-style mock objects are invaluable. I had a situation a while ago where we had a suspect XML message being sent over the wire to an external system. We wrote an integration test where we injected a mock for the external system into a complex object structure – the mock was primed to only accept a valid XML message – and when it failed the stack trace gave us a direct line into the failure. It turned out one of the eight objects wired together was doing an incorrect transformation on part of the XML which meant the outbound message was invalid. By using a mock object in this way we were able to identify exactly where the error was occurring.

However nowadays mocks are mostly used for describing interactions between objects in the context of test-driven development. Your object under test interacts with one or two other objects that you represent by interfaces (roles) that you probably inject into its constructor as mocks. Your test is verifying that the object calls the appropriate methods on its collaborators. In this simplistic scenario, the reason for a failure is usually pretty obvious – you haven’t written the code yet or you are passing the wrong parameters into the method call.

Say you are developing a simple calculation where you expect the answer to be 7 but the code is producing the answer 10, then it isn’t that difficult to work out where the problem is. You don’t need the code to fail as soon as the value of 10 is produced. The fact that the answer is 10 and you expected 7 is enough to triangulate the error. This is classic post hoc state-based testing. Similarly, if you expect your object to call makeCheese on the CheeseFactory and it doesn’t, well you are likely to have a pretty good idea where it doesn’t. So all you really need your mocking library to do is act like a flight recorder black box. You can ask it after the fact: hey CheeseFactory, did my object call your makeCheese method? If it didn’t you probably know why. (And if you don’t it may be an indication that your test is too complicated.)

A more intuitive approach to mocking

This then means that you can treat assertions on method calls just like you treat assertions on state changes, asking the various collaborators what happened after the fact rather than priming your mock objects ahead of time, which in turn means you don’t need to turn your brain inside-out creating a flow like this:

  // Given
  // ... create mocks
  // ... wire up my object

  // Expect (eh?)
  funky.dslWith("stringsForMethods")

  // When
  myObject.makeBrie();

  // Then
  verifyExpectationsSetTwoParagraphsEarlier(); // you remember right?

where it is much more intuitive to write something like:

  // Given
  // ... create mocks
  // ... wire up my object

  // When
  myObject.makeBrie();

  // Then
  verify(CheeseFactory).makeCheese("brie"); // how nice is that?

This, then, is the premise of Mockito. It uses a similar syntax to EasyMock – which means my generics-aware IDE is able to do proper completions and refactorings – but it doesn’t have any of that record/playback nonsense. Nor does it require me to do any of the clever @{{ anonymous constructor }}@ gymnastics that JMock 2 introduced. It just sets up mocks on interfaces (although it allows me to mock concrete classes which I think is a retrograde step – remember kids, mock roles, not objects) and gives me a black box recorder that I can interrogate after the fact.

When I asked Mockito’s author, Szczepan Faber, how he came up with the insight that mocking in the context of TDD was a completely separate problem from endotesting, he replied: what’s endotesting?

It turned out that in order to create a mocking framework to support TDD it helped to have no idea where the encumbent frameworks – JMock and EasyMock – had come from. In the same way that a unit testing framework got co-opted as the enabler for TDD in Java, an endotesting framework became the enabler for method assertions in interaction-based testing. But if you start from the ground up – with a nod to EasyMock and with a pragmatic dose of Java 5 generics – you can get a simple, elegant and intuitive framework for verifying interactions between collaborators. There’s still a place for traditional endotesting in the context of gnarly integration tests, but I’m liking Mockito. I think you will too.

JBehave 2.0 is live!

September 8, 2008
agile, bdd, jbehave, open-source, programming, software, tdd
1 Comment

Some ancient history

Back in 2003 I started work on a framework called JBehave. It was an experiment to see what JUnit might have looked like if it had been designed from the ground up for TDD rather than as a unit testing framework. I was also starting to use the phrase “behaviour-driven development” to describe what I meant. The jbehave.org domain was registered and the first lines of code written on Christmas Eve 2003, much to my wife’s bemusement. Over time JBehave grew a much more interesting aspect in the form of a framework for defining and running scenarios, or automated acceptance tests.

Since JBehave wasn’t based on JUnit there was always going to be a barrier to adoption in the form of IDE integration and build tools, among other things. It also failed the First Law of Frameworks in that it wasn’t harvested from real life – it was just an extended thought experiment. As a result it turns out it was a bit of a cow to use. Mea culpa.

Some recent history

Many of the ideas from JBehave have since appeared in other BDD frameworks, particularly in the lovely rspec. Although I wrote the first cut of the scenario runner in rspec it has since been thoroughly reworked and improved beyond all recognition1 by the efforts of David Chelimsky and his team. The biggest single improvement has been the introduction of plain text stories, which allow you to separate the scenario text from any of the automated steps they refer to.

Over the last few months, Liz Keogh and Mauro Talevi have completely rewritten JBehave from the ground up, taking advantage of new Java 5 language features and using JUnit 4 as the underlying execution framework.

By using real project examples to drive the design – including using it in their day jobs – they have produced what I believe is a powerful and very usable behaviour-driven development framework for Java. In particular Liz decided she wanted plain text scenarios and the idea of a “pending” scenario – something that you have identified but not yet implemented.

And now…

We’ve released it! JBehave 2 has only been live for a few days and already ThoughtWorks colleague Ryan Greenhall has written an excellent tutorial demonstrating how to use it. Quoting the release announcement on the site, JBehave 2 supports the following feaures:

  • Plain text scenarios
  • Support for multiple scenarios in a file
  • Pending scenarios (the “Amber Bar”)
  • Clear, easy-to-read output from failures and pending scenarios
  • Maven support
  • Parameter capture from scenarios
  • Conversion of parameters to your own objects
  • Support for multiple languages and scenario terminology
  • A high degree of configurability

Go download JBehave 2 and take it for a spin, and let me know what you think. The mailing lists are waiting for you too.

1. Aslak Hellesøy is currently working on a replacement for the rspec scenario runner called Cucumber which looks very promising.

Learning to Lean

June 29, 2008
agile, coaching, dreyfus, lean, learning
1 Comment

A discussion unfolded recently on an internal mailing list that tied together two of my favourite topics, namely learning theory and Lean.

Someone was asking how they might apply Lean to setting up and running a new project. A number of people made suggestions, all of which were the kind of good common sense I would expect from my ThoughtWorks peers, but what particularly struck me was the way the answers exemplified the different stages of the Dreyfus Model of Skills Acquisition. (The link is to an interview with pragmatic programmer Andy Hunt, whose forthcoming book Pragmatic Thinking and Learning contains an excellent chapter on it).

[prag-book]http://pragprog.com/titles/ahptl/pragmatic-thinking-and-learning

The Dreyfus Model of Skills Acquisition

As well as providing a useful description of each stage of learning, the Dreyfus model describes how best to help the learner progress to the next stage in their learning.

[cc-model]http://en.wikipedia.org/wiki/Four_stages_of_competence
[shu-ha-ri]http://en.wikipedia.org/wiki/Shuhari

According to the Dreyfus model there are five distinct stages, as the learner gains experience and develops insight and intuition. Very briefly:

The Novice wants recipes, best practices, quick wins
The Advanced Beginner wants guidelines, a safe environment to make mistakes
At the Competent stage you want goals, freedom to execute
The Proficient learner wants maxims, war stories, metaphors
The Expert wants philosophies, discussions and arguments with other experts(!)

So back to the mailing list discussion, here’s what I saw in amongst a number of responses. (I’m paraphrasing and summarising for effect.)

Novice: I like the sound of Lean and I want to apply it to my next project. Where should I start?
…
Competent: Here’s my cheat sheet of Lean practices and behaviours.
…
Expert: Lean isn’t a process, it’s a philosophy.

Perfect!

So why such a wide spread of different answers? The problem is that when it is applied to software delivery, Lean is a metaphor, which means it’s too abstract for a novice to “just use” without making it situationally specific, and too concrete for an expert to articulate easily. For example, the Lean concept of inventory applies in a number of subtle ways to software delivery.

It is worth mentioning that the Dreyfus model is about describing the acquisition of a specific skill – in this case applying Lean theory to software delivery – and not a general categorisation of an individual. For instance the author of the reply from which I took the “competent” fragment above is an accomplished agile coach and developer, so be careful not to take the Dreyfus descriptions out of context. (But you wouldn’t do that, would you? I meant the others.)

Getting started with Lean

So then I thought, what would be the most useful advice to an experienced Agile team lead to get started? To kick a project off in a Lean way, I would suggest the following:

p(. 1. Get everyone immersed in some Lean theory. Use workshops with lots of interactive exercises. Be aware they are at the novice stage so they will find rules and recipes – and quick wins – more useful than context at this stage, even if the specifics aren’t strictly correct. “It depends” is never helpful here. Ship in your local Lean expert – Richard Durnall or David Anderson in my case – and steal some collateral from the intertubes. Share with the team that you’re new to this too – it will make them less afraid.

[david-anderson]http://www.agilemanagement.net/Articles/hidden/Biography.html

p(. 2. Think about how Lean applies to software delivery. For instance, there are three “flavours” of Lean, namely Manufacturing, Supply and Product Design. Although they all focus on minimising waste, they also have specific targets in mind.

  • Lean Manufacturing is about minimising variance (you want all the cars to come out the same). This is analogous to build, deployment and running automated test suites. The same code should always produce the same deployable artefacts. Test runs should be idempotent (rerunnable with the same results).
  • Lean Supply is about minimising inventory. This is analogous to deferring decisions, doing enough up-front analysis and design but no more (and certainly not none, otherwise you starve your supply). Have a nominal backlog of features but don’t bother planning out 3 months of detailed Master Story List (that term should never have made it out of the gate). Carry out exploratory testing soon after the feature is code complete, when it’s still fresh in the developers’ heads.
  • Lean Product Design is about maximising discovery. Everything is an experiment, and if you don’t learn anything it wasn’t useful. This is analogous to writing software, understanding and articulating requirements, user experience workshops, designing effective tests, identifying corner cases. Foster an environment where it’s ok – in fact encouraged – to try new stuff “just in case”, or run two or three ideas in parallel to see which one fits best. That isn’t waste, it’s a good discovery habit that you can position as due diligence. Read up on innovation techniques and creating an innovative working environment. Your programmers aren’t building cars – they’re designing cars. Let them. Make it fun.

p(. As a example of mis-applying the metaphor, methodologies like six sigma mistake innovation (discovery) for waste (variance) so they squeeze the innovation right out of the process. (They call innovation, sorry variance, “defects” – cute.)

[six-sigma]http://www.isixsigma.com/sixsigma/six_sigma.asp

p(. 3. Break down your process into swimlane steps. It doesn’t matter whether it’s right (it won’t be) or whether it fully describes your process (it won’t). What matters is that people are thinking in terms of moving something from an idea to signed off, deployed code (“from concept to cash” as Mary Poppendieck describes it). Use simple index cards to represent work on a big visible wallchart. Moving a card across swimlanes is a small win. People like frequent small wins.

p(. 4. Keep track of where the cards back up. This is a clue to bottlenecks. It may not be that the backlog itself is the problem – it’s just a starting point for your investigation. Apply a systems thinking approach – what could be causing that? What else?

p(. 5. (once you’re getting the hang of it) Apply Lean thinking to your process itself. That’s one of the cool things about Lean. It’s not just about getting work done – it’s about getting better at getting work done. This is when you start looking at your process and identifying the actual value stream as opposed to “the stuff you do”. Are there activities that are just there because “we always do that”? Are there things you spend time on that are so “obvious” you didn’t bother capturing them as their own swimlane?

There’s a ton of literature out there about Lean – and some of it is quite good – and a small-but-growing body of Lean practitioners within the software industry. We can’t actually clone Richard Durnall, but we can learn from him. As long as we choose to believe we’re always learning, we should be in pretty good shape.

ps. Another quote from the Lean expert on that email thread – Richard again – was that there aren’t Agile projects or Lean projects, “there are just projects”. This reminded me of a famous Bruce Lee quote. “Before I studied the art, a punch to me was just like a punch, a kick just like a kick. After I learned the art, a punch was no longer a punch, a kick no longer a kick. Now that I’ve understood the art, a punch is just like a punch, a kick just like a kick.”

[bruce-lee]http://www.fightingmaster.com/masters/brucelee/quotes.htm#On%20simplicity

Awesome Acceptance Testing at SPA 2008

February 22, 2008
agile, events, spa, talks, tdd, testing
4 Comments

I’ve been pretty slack at letting people know about upcoming talks. I could blame workload or burnout or any number of other plausible-sounding reasons, but a lot of it is just down to not prioritising very well. I should fix that.

A couple of years ago Joe Walnes and I gave a talk at an XP Day entitled “Awesome Acceptance Testing” (blame Joe for the title). We looked at motivations for acceptance testing and discussed various strategies, tools and techniques. But mostly it was an opportunity to get a bunch of people in a room and find out what they thought and what they were up to in the acceptance testing space.

If you didn’t get to see it and it sounds like fun, we’ll be rerunning the session at SPA 2008 in March. I hope to see you there.

Goal-oriented vocabulary – saying what you mean

February 12, 2008
agile, bdd, design, language, problem-solving
13 Comments

I was in a hotel in Stockholm recently and I noticed a bottle opener attached to the wall in the bathroom. There was a bilingual sign under it which got me thinking about the term “bottle opener” itself. (I was giving a talk about BDD the next day so I was already thinking about how language is used.)

It occurred to me that “bottle opener” is a great example of goal-oriented vocabulary. The device itself is actually a cap remover, and it only works on one particular design of metal cap. The reason I use it, however, is to enable me to get to the beer in the bottle. Hence “bottle opener” rather than “cap remover”.

The task is just detail

There is more to this than just linguistic curiosity. If you use task-oriented vocabulary it can cause you to focus on the means rather than the goal, which in turn can limit your options. My favourite example of this is the term “search engine”. Searching is the activity I have to do because I’ve misplaced my keys and I’m locked outside. What I want is a find engine!

Google realises this. When I type something into Google, it guesses what I’m likely to be trying to find, not what I happen to be typing into the box. If I type in “Stockholm map”, I’m likely to be looking for a map of Stockholm (first three results are actual maps – presented as pictures) or some information about the town itself. If I type “hotels Stockholm” I’m probably planning a trip there and voila! lots of useful results for the traveller. Other “search” engines do just that – they search, and produce lists of results. It’s then down to me to sift out the ones I care about to get me closer to my goal.

“Blur” on a problem

We talk about “focusing on a problem” in order to solve it. This is a task-oriented phrase. An alternative would be to stand far enough back that you see the problem in its proper perspective. If anything you are “blurring” on the problem – deliberately losing focus on the detail to see if any larger-scale structure emerges.

I often describe BDD as outside-in development. You start at the outside with an automated scenario, and work inwards, discovering services and collaborators as you go, until you’re done. With a legacy application it can be difficult to remain outside enough, or to get a good enough frame of reference for “done”. Blurring can help with this.

For the last six months I’ve been involved in restructuring and re-architecting a legacy code base. It’s been quite a major undertaking, and has involved a number of false starts and dead ends. (I’m planning to write it up as an experience report at some point, but given my current throughput of things I plan to write, don’t expect it any time soon.) During this project, I’ve often found myself struggling to choose between alternative strategies, or unsure of where to go next. In these situations I’ve found that stepping back and “blurring” gives me enough perspective for one of the alternatives to become “obvious”. In fact a couple of my teammates have picked up on this and will actually suggest it as an activity when we are pairing. “We’re thrashing here – let’s step back and start from the outside again.”

It could be as simple as asking “whose responsibility is this feature?” or “who is the actual client of this method call?”. You don’t need to know the answers – just verbalising the questions can give you enough “blur” to gain a better perspective.

Blur on time as well as space

Linus Torvalds recently gave a talk where he said the problem with source control isn’t branching, it’s merging. Again, by taking a broader perspective – in this case temporal rather than spatial – his insight is that the goal is a successful merge some time in the future, not the task of branching now.

As a final thought, while I was thinking about this I realised the term “behaviour-driven” contrasts with “test-driven” in a similar way. My goal as a developer is to deliver a system that behaves in a particular way. Whether or not it has tests is an interesting metric, but not the core purpose. “Test-driven” development will cause me to have lots of tests, but it won’t necessarily get me nearer the goal of delivering business value through software. So you can use goal-oriented vocabulary in your development process as well as your code to help maintain perspective on what you are trying to achieve.

_Props to James Lewis for helping me formulate these ideas. And for being really good at perspective._

Empty rooms

October 9, 2007
agile, bdd, events, oopsla, tutorials
7 Comments

It’s now about two weeks to OOPSLA, where Liz Keogh and I will be presenting a workshop on behaviour-driven development using JBehave. This will be along similar lines to the workshop I co-presented at RailsConf Europe last month.

At RailsConf we presented to nearly 200 people, which was about a quarter of the conference attendees. At JAOO last year Niclas Nilsson and I presented BDD to well over 100 people. So far at OOPSLA only a handful of people have signed up for the workshop. I’m curious. Is it that the people attending OOPSLA aren’t interested in behaviour-driven development? Is it JBehave? Is it that we haven’t marketed it very well? Is it simply the cost?

RSpec, the ruby equivalent of JBehave, is comparatively much more popular. It has been embraced by the Rails crowd and by rubyists in general in a way that JBehave doesn’t seem to have been in java. Perhaps JUnit and JMock were already so pervasive in the agile java community that there wasn’t room for JBehave, or perhaps it wasn’t seen as different enough to be worth trying – its early incarnations were as just another TDD and mocking tool.

Since I started writing JBehave back in 2003, BDD – and JBehave itself – has broadened in scope, covering user stories right the way through to tested, deployed code, and the OOPSLA workshop will explore this bigger picture. It will be of interest to anyone looking to understand behaviour-driven development, regardless of the technology stack or toolset you use.

On a related theme, java is trailing behind ruby and even C# in terms of customer-friendly executable documentation. JBehave might just be the tool to follow through on the promise of FIT, to define executable acceptance criteria that can be authored by testers or analysts.

So to anyone going to OOPSLA, if you aren’t coming to the BDD session I would be very keen to hear why so I can pitch it better next time. Is it that you aren’t using JBehave so you don’t think the session is relevant? Are you simply not interested in BDD? Is there too much other good stuff on at the same time? Or did you just not notice but now you have you’ll be signing up? I hope to see you in Canada!

Upcoming events

September 10, 2007
agile, bdd, coaching, events, programming, ruby, talks
5 Comments

So it’s that time of year again. I’ve got a number of conferences and workshops coming up, ranging over all sorts of topics. I just popped over to Martin Fowler’s site (I’m doing a talk with him this week) and noticed that he has a much more organised setup than me. All his events are in a sidebar and there is a handy link if you want more details. Another idea to go on my to-do pile.

ThoughtWorks Quarterly Technology Briefing

  • Manchester – 12 September 2007
  • London – 20 September 2007

This is the second instalment in ThoughtWorks series of informal sessions aimed at technologists across the spectrum. Although calling it a technology briefing is a bit inaccurate because the title for this one is “How to Sell Agile to your Organisation”, which has far more to do with the themes of people, risk and change than with anything technological.

This is the talk I’ll be presenting with Martin so I can guarantee a lively session. In his own words: “As I detest selling anything to anyone it will be interesting to see how this talk works out.”

Details and registration info are on the ThoughtWorks website.

RailsConf Europe

  • Berlin – 17-19 September 2007

A lot of Ruby folk seem to have taken to behaviour-driven development. This is almost entirely due to the success of the rspec project, which is in turn due to the enthusiasm and dedication of its developers and the community they have established.

A while back I wrote a story-level BDD framework for Ruby called rbehave which has since been integrated into the rspec project.

I’ll be helping rspec project leads David Chelimsky and Aslak Hellesoy present a workshop entitled A half-day of behaviour-driven development on Rails, where we’ll be demonstrating how rspec helps you write software that is focused on achieving an outcome. It’s at 8:30am on the Monday morning, so make sure you’re there first thing.

Expo-C Roadshow

  • Växjö – 15-16 October 2007
  • Karlskrona – 17-18 October 2007

Expo-C is one of my favourite events. It’s a small conference in south-east Sweden and it seems to attract an audience that really cares about what they are doing. I’ve done two of them now, on very different topics, and on both occasions I was very impressed with the quality of the attendees and the calibre of the other speakers. (I’m usually the only one there who hasn’t written a book.)

This time they are doing two mini-conferences back to back, in Växjö and then Karlskrona, with a tutorial day and a seminar day (six sessions) in each location. I’ll be running full-day tutorials on BDD in Växjö, and Coaching, Communication and Change in Karlskrona. For the seminar I’ll be talking about bridging the communication gap, based on a keynote I gave with Martin Fowler at QCon earlier this year.

I will also be learning how to pronounce “Växjö”.

OOPSLA

  • Montreal – 21-25 October 2007

This will be my first OOPSLA. I’ve heard a lot about it and I’m a bit intimidated. By reputation it seems a bit more “cerebral” than most conferences. It will also be the first time I’ve ever presented JBehave at a conference. No mean feat considering I started writing it at the end of 2003! There’s perpetual beta for you.

My co-presenter is my ThoughtWorks colleague, friend and cybergoth Liz Keogh, the person responsible for getting JBehave to 1.0. I have huge respect for Liz; she manages to combine software with poetry. This isn’t a pretentious metaphor – she actually does combine software with poetry. She ran a haiku workshop at a previous ThoughtWorks away day that many of the attendees nominated as the highlight of their day. She also writes inspiring and inspired blog articles.

I’m only going because I want to see what Liz does when she’s let loose on a roomful of developers. I reckon we’ll end up writing haiku acceptance criteria.

And some others…

There are another couple of events in the pipeline that I will blog about nearer the time (January and February next year). After that I’m going to have a bit of a lie down.

Correction: I got the dates wrong for OOPSLA. Thanks Joshua Graham for putting me straight.
_Another correction: My Swedish geography is appalling. Thanks Morgan Persson._

SOA for the rest of us

September 2, 2007
agile, architecture, articles, programming, services, soa, software
13 Comments

Earlier this year I wrote an article to introduce service-oriented architecture to non-technical people. It was published in the May 2007 issue of Better Software magazine.

The kind folks at Better Software have allowed me to provide a PDF version of the article, complete with retro 1950s graphics. You can also read it as a single html page.

Please post any comments here, because I’ve disabled comments on the page itself.

Follow

Get every new post delivered to your Inbox.

Join 197 other followers