Andrew Ferrier

After euroGel 2006, which was truly a ‘good’ experience for me, Mark Hurst has announced that euroGel is coming back to Copenhagen in 2007. I’ve just booked my ticket, and as a previous attendee, I’ve got a 20% discount, so the price was only USD $480. I’m allowed to share this discount (which is only valid until this Friday, 22nd September) with friends and colleagues, so if you’re interested, let me know and I’ll send you the link. You can sign up at the regular price here.

I’m already looking forward to this conference, and it’s almost a year away.

Joe McKendrick discusses SOA and reuse in a recent blog entry, essentially drawing on some comments from David Chappell that reuse didn’t do as well as predicted in the era of object-orientation, and that SOA isn’t faring well in this department either. Dave Linthicum, in his latest podcast, also discusses this topic.

I’m not sure I can comment that widely on the state of current SOA projects, and I would agree that SOA may suffer from similar management problems to that of object-orientation: if developers of SOA systems aren’t rewarded for saving time with a reuse strategy, they won’t be enthused to do so. This is an important part of any software project, and encouraging reuse is a best practice that shouldn’t be restricted to object-orientation or SOA.

However, whilst I agree that SOA has other benefits apart from encouraging reuse, I have a fairly high opinion of its potential in that respect. It’s important to understand what we mean by reuse. Reuse rarely means using an object or service as it is. There is often a mismatch between the interface offered by the service (object) being consumed, and the service (object) that needs to call this interface. Expecting anything else is unrealistic (even if future reuse plans are made). This is often solved using something like a façade pattern in object-oriented languages, and some form of mediation with services (such as that offered by WebSphere ESB). The latter is often easier, because there is a lower degree of coupling than inside a single programming language, and because programming code is not often needed, and this is why I believe SOA reuse is simpler – if done well. Of course, some work is still required, but this greater ease of reuse makes it a realistic strategy for more scenarios.

I would agree, however, that, as is often the case, the project management problems here are the greatest ones.

I spent last Thursday and Friday in London at the Google offices in Victoria for the first Google Test Automation Conference. The presentation topics ranged widely, considering the relatively narrow scope of the conference, but most were well developed and interesting, even if some retrod familiar topics. Some of the highlights included:

• Steve Loughran and Julio Guijarro, HP Labs. This presentation was about Smartfrog, a system deployment framework, which Steve and Julio were working on as part of a strategy for system testing. They demonstrated several examples of how the system might work in practice. Smartfrog looks pretty flexible, and I plan to spend some time looking into it. Frameworks for deployment have an inherent problem in catering to the wide variety of platforms, configuration mechanisms, deployment combinations and so on that are necessary in practice. Anything that gets closer to this is therefore welcome. Smartfrog also has the interesting property that the XHTML it produces as output is sufficiently well-formed that, although it has an embedded CSS stylesheet for presentation in a web browser, it can also be parsed as XML data without much effort, and thus act as a machine-readable data source as well. This might seem obvious to some folks, and I’m willing to bet it’s not the first time it’s been done, but it seemed novel to me.
• Robert Chatley (a fellow alumnus from Imperial College) and Tom White, Kizoom. Tom and Robert were talking about what they called literate functional testing. Essentially this involves creating tests, in this case written in Java, that use plain English for method names, variables, and so on. This means that once punctuation is stripped out, Java code – test assertions – become statements that are readily understandable by non-programmers (such as the business analysts in their organisation). Their framework will shortly be available on Google Code.
• Andreas Leitner, ETH Zurich: Andreas discussed automated testing using contracts. Essentially this means using a language which has pre-conditions and post-conditions on methods, and optionally assertions on objects. He has developed a testing framework called AutoTest, using the Eiffel language, which has these features built in (similar extensions are available for more mainstream languages such as Java). Once these restrictions are placed on a program, generated input can be used to determine whether methods behave as they should. A number of strategies are available for generating this data, and they are pluggable into Andreas’s framework. The simplest is of course to generate the data randomly, but other, more sophisticated strategies are available to improve coverage. Andreas stressed that this type of testing, which is essentially fuzz testing with intelligence, should be used to complement human-created unit tests, not to replace them.
• Goranka Bjedov, Google: Goranka explained some of the background to performance testing, including the differences between performance testing, stress testing, load testing, scalability testing, etc., and how to deploy and manage performance testing systems.
• The conference finished with 10 lightning talks. Subjects covered included jMock (a mock objects framework that complements JUnit), justifying automated tesing in financial terms, testing heresies, Yandex (the largest search engine in Russia, their share ~60%, Google’s ~6%), ‘Automated Testing: Why bother?’, automated tricks for manual testing, and the Perl-inspired Test Anything Protocol. I hadn’t seen lightning talks before, and I thought they were a fantastic idea – similar in some ways to the Straight 8 showings I wrote about a while ago – if you don’t like what you’re seeing, something else is coming along soon. More presentations should be like this.

My thanks to the guys at Google for hosting this conference, particularly for free. The original call for attendees was on their research blog. Some of the conference topics were quite academic and in-depth, but that provided a good constrast to the more practical topics. Google’s offices and facilities are also impressive – definitely worth visiting if you get the chance.

Google LTAC

Henrique’s recent comment reminded me of another interesting bunch of people I met at euroGel 2006: the incoming class of the Kaospilots, ‘The most unusual school in the world‘. They sound like an indie band, but Kaospilots is actually a private university, teaching business and related creative subjects. They are partly self-funding, and the concept seems novel – all teachers are external consultants. The most striking thing I found in the students I met was their drive – it’s obviously not a university course you drift onto. I think this university model is worth keeping an eye on.

I’ve just come back from the Good Experience Live (euroGel) conference in Copenhagen (more on the city and Denmark in a later post). It was a superb and surprisingly moving experience, and as a conference that I paid for myself, I would say it was worth every penny for personal development reasons alone. I would recommend it to anyone with a wide range of interests.

The theme of the conference is hard to pin down; it is defined as ‘good experience in all its forms’. I’m still struggling to ‘get it’, but it didn’t seem to matter that I didn’t. In practice, this seems to mean a variety of speakers from across the arts and technology, some of them specialising in user experience or customer experience, coming together to share their stories.

This is the first time the conference has been run in Europe (it has been run in New York City since 2003), and current indications are that it will return to both places. The creator of the conference is Mark Hurst, who also leads the sessions at the conference, and who I unfortunately didn’t get to meet. A large number of the speakers are obviously personal friends of his and there is accordingly a sense of community, which is also explored online (see the Gel blog category on goodexperience.com)

The presentations were almost all entertaining, and most informative and passionate. Some of the highlights were:

• Han Bennink – I’m ashamed to admit I’d never heard of Han before. It turns out that he is one of the top Jazz drummers in the world, and his natural exuberance for his work was obvious for all to see – a man who managed to enter the stage, drop a bunch of metal pipes haphazardly on the stage, and make it part of his performance, he obviously has more talent than just a natural sense of rhythm.
• Stephen Bauman – Stephen is a Methodist minister in New York, and in true ministerly style, he told stories. These helped to illustrate what he called ‘Basic Truths’ (on which he has also written a book). I was lucky enough to discuss these and others things with him later on, and he struck me as an extremely perceptive and open-minded religious man: an inspirational American preacher who didn’t hector about Jesus.
• Alison Young – Possessed of a beautiful voice, Alison Young is a supremely talented singer with Southern influences. Why she isn’t more famous is a mystery to me.

I also met some interesting folks:

• Kareem Mayan – Kareem is a returning Gel participant (and volunteer), and obviously enjoys it greatly. His blog has some interesting discussions about emerging technology, including plenty of media and YouTube links (including this ‘How to drive a stick shift’ video – sadly, this doesn’t impress chicks here in the UK, where manual cars are the norm).
• Alexander Kjerulf - Alexander is an irrepressibly bubbly fellow, and describes himself as ‘The Chief Happiness Officer’. He writes and consults on happiness in the workplace, and his passion for his work is obvious. What he says is not rocket science, but it bears repeating. His blog is well worth a read.

I was also lucky enough to win one of the prize draws – for a set of books written by some current and previous Gel speakers, so I now have the following to work my way through:

• Bing Get Dressed by Ted Dewan
• To the Desert and Back by Phil Mirvis and others
• Net.art Per Me by Vuk Cosic
• Bosch & Fjord by Bosch & Fjord
• Simple Truths by Stephen Bauman
• All Marketers are Liars by Seth Godin
• Life Between Buildings by Jan Gehl
• The Power to Heal by Rick Smolan
• From Alice to Outback by Robyn Davidson

Thanks to all the folks who donated books for this – and to Mark Hurst and his team for organising euroGel. I will go again.

Update 2006-09-12: Alison Young’s website can be found here.

Lengthy and vacuous job titles are increasingly common in many organisations. It’s not uncommon to see ‘User experience practice leader’, ‘Technical data specialist’, ‘Revenue protection officer’, ‘PBT supplier’, ‘Guide planner’, ‘Authorising supplier manager’, or ‘Integrating management expert’. They probably make sense to people in that organisation, but to everyone else they seem like goobledygook.

(Note: I made most of those up – only one of those titles is real – guess which? However, they all use widespread vocabulary, so hopefully they seem familiar.)

Specialisation is good. However, these job titles don’t describe what people do, or even what they are supposed to do. They are vague, and hence they’re dangerous, because they obfsucate the intended structure of their organisation. One of the key tasks for a business is to continually identify mismatches between what people are supposed to be doing, are actually doing, and what needs to be done. This is critical to remain efficient. However, it’s hard when everyone sounds important, and key to the organisation (because, let’s face it, some probably aren’t). So organisations that are self-indulgent with their job titles (perhaps as a retention technique?) aren’t doing themselves any favours strategically.

Please let’s try to move to a world where we can tell what each other does.

So let’s imagine you’ve sent a document out to a bunch of people for their review and comments, and you’re currently going through the process of updating it with their corrections, clarification requests, and so on. How do you know when the document’s done? Well, how long is a piece of string?

I’d propose the following rule of thumb:

Take the number of valid review comments you receive from a particular person, and call that a. Take the number of times you recieve comments that require you to point someone at a part of the document they’ve missed (let’s assume it is well organised), and call that b.

Divide a by b – this is the review quotient.

As this number tends towards zero, you know that the document is becoming ready. For most purposes, 0.1 is probably a good threshold for determining when to stop making further changes. It’s close enough to zero that the S/N ratio is now overwhelming you, and your time is better spent on something else.

Scott Berkun‘s excellent book, The Art of Project Management, contains a chapter on ‘Power and politics’. In it, he describes a realisation he had – from thinking that politics was something practised by selfish and evil people, to thinking that it was a useful skill to develop – something everyone does, for better or worse.

His prose convinced me, and I am encouraging myself not to put things I don’t like down to ‘politics’ but instead to try and understand them at a deeper level. I think there is a great temptation to put problems and shortcomings down to politics, without realising that it’s part of the way human beings interact and not something that’s disposable, however ‘nice’ everyone is. Ignoring it is intellectual laziness. I think the reason I found it hard to face up to this truth before was that I thought I didn’t understand politics, but Scott makes it easy – with descriptions of different types of power, where it comes from, and how to influence those who have it. Practicing politics is still hard, but it’s worth trying to improve one’s skill.

(Note: I’m talking mostly about office politics here, but some of the lessons carry outside that domain – that’s just where I have most experience).

There’s a tradition in the technology industry of a ‘user’. This, apparently, is the poor sod who’s going to ultimately use whatever you’re creating (software, steering wheels, microwaves, and so on). We’re not sure exactly who he is, but he must exist, right? Many of the more theoretical parts of software engineering use this term, for example: user-centered design, user interfaces, user error (a most horrifically arrogant expression), etc.

As a work for a commercial company, I resolved to give up using this word a few years ago, and call these entities ‘customers’ instead. I figured this would encourage me to be more customer-centric (duh). I’ve been relatively successful at giving up my addiction to ‘user’, and use of ‘customer’ reminds me that a feature / bug / product that isn’t important to one of our customers, although it might be important to a ‘user’, isn’t important to me either. After all, we’re here to make money, right?

But a recent article of Don Norman’s has convinced me that this approach, too, is damaging. Not as harmful as ‘user’, but still wrong. ‘Customer’ works fine for the business. But customers don’t want to be customers. They want to be people, and they want you to care about them and their needs. Thinking of them as people is a reminder that they have human values and failings, and should be recognised in a human way rather than as entities who exchange money for goods and services. Of course you want that exchange, but you don’t want them to feel like that’s the sole purpose of your relationship – otherwise you exclude yet another way for you to differentiate yourself from your competitors (others of which include producing good quality products, cheap products, faster-to-market products, and all the others we know and love).

As such, I plan to try and wean myself off ‘customer’, and onto ‘people’. Please let me know if I lapse.

I work in software development, where process is a hotly-debated topic (some think there should be little, some a lot, some think it should be of this type, some of that). Some people can’t even spot a process when it’s staring them in the face, and, to be fair, the definition of processes is not exactly cast in stone.

Scott Berkun understands processes well. He makes an accurate analogy between a good process and the white lines separating lanes on a highway: they restrict the (intended) movement of vehicles, but help everyone to travel faster and more safely. They don’t intrude, they help. Perhaps a slightly more tenuous extension of this analogy to bad processes would be where the lines are constantly shifting about or the lane schemes being re-arranged, in an attempt to improve matters, but actually confusing everyone and slowing them down.

So the important thing to understand is that more process is not necessarily bad, more bad processes are bad (for example, in software products of any significant size, some level of source control is a good thing – but awkward source control will annoy people and encourage them to find ways round it). Over lunch I was listening to some colleagues talking about process, and I came to an important conclusion:

• People whose sole job is to invent and maintain processes will almost certainly come up with bad ones.

This is because they have no motivation to help, only a motivation to keep their job going, and that means more process (and probably ill-thought-through process). Processes should, with some minor exceptions, be invented with participation from those they affect, as they have a motivation to get it right. If there isn’t a strong enough motivation for them to help come up with a process, they obviously aren’t being bothered enough by the status quo and the process probably isn’t necessary.