Postcard from QCON

An agile conference

It was interesting to compare this QCon conference with Microsoft's Architect Insight conference. Without denigrating an interesting Microsoft conference, QCon ran longer and had a wider scope (it wasn't just for architects; neither for just one platform) and a more mature architectural content (the people responsible for running Amazon and eBay really do have something worth listening to).

Taking the scope beyond the architectural profession is healthy even for architects - as I've quoted Martin Fowler, speaking at QCon, before, “We sometimes have trouble with the term Architect at Thoughtworks, mainly because of some of the people we meet calling themselves architects”.

On the other hand, it makes it harder to sum up the conference in a short article – Kevlin Henney's thoughts on moving beyond functional requirements (“non functional requirements” is such a misleading term; perhaps “operational requirements” is better) were interesting but I'm not about to précis (steal) them here – if you want to read them, no doubt they'll appear in his articles in Reg Developer in due course.

One highlight for me was Larry Constantine's talk on user-centred design and why it might be considered harmful (background reading here and here.

I learned structured software design from Yourdon and Constantine's books; and something about peopleware from Constantime on Peopleware (Prentice Hall, ISBN 0133319768). He gave a scathing analysis of why the Microsoft UI manages to be so annoying, despite its good intentions.

Ask the users what they want and they'll tell you – usually providing a half-cocked design solution instead of genuine requirements Ask what else they want and they'll find something more to say. Put a wish list up on the end of a premium rate number and they'll pay you just so they can criticise you (sometimes Microsoft is so clever) – and come up with yet more “wants” to be treated as “must haves”.

When the resulting interface gets so bloated it obviously doesn't work, you don't blame the process, you blame the task bar and redesign it with ribbons and other, even more complex devices. And why can you then only customise a little bit of, say, the Vista UI? Well, perhaps the UI people wanted it all customisable (Microsoft does employ some pretty good people, who really know their jobs) and the programmers simply ran out of time....

OTOH, perhaps, as Reg Developer contributor Tim Anderson suggested to me afterwards, poking fun at this sort of thing is too easy. But it's fun. Although Constantine's picture of using UML for designing UI (he compared it to an elephant painting portraits; you're amazed it can be done at all, never mind the quality – which is a rip-off of a non-PC Samuel Johnson quotation: 'A woman's preaching is like a dog's walking on his hind legs - it is not done well, but you are surprised to find it done at all') hit the wrong target, I thought. As so often with UML (and SQL and other standard languages), although it shouldn't be unleashed on users, this doesn't make it useless. There's nothing wrong with providing a user-friendly UI design tool, it seems to me, which builds an underlying UML model in the background, that can then be verified and transformed into UI code.

Werner Vogels, Amazon's CTO, described a pretty agile, not to say chaotic, environment at Amazon. Early on, time to market and achieving volume was everything. Which is fine, but early Amazon didn't scale – bung in a mainframe and it just ran out of steam; every Xmas rush was a panic, followed by a short sense of relief, quickly succeeded by a panic about next Xmas.

Amazon re-architected successfully for scalability, using a service-based approach, but it took longer than expected (some six or seven years) – there is nothing wrong with compromising architecture for tactical business advantage, provided that you recognise and accept the consequences and have contingency plans to deal with them. And the right culture. But human nature is such that most people ignore consequences in the face of initial success – and, perhaps, designing the architecture for scalability as well as rapid acquisition would have been a better approach in the first place. As first to market, perhaps Amazon had the luxury of being able to do things wrong – later competitors won't be so lucky.

An interesting insight into consequences is that Amazon can't really sell its software, no matter how tempting the offer – it simply wasn't written well-enough (I'm not sure Vogels put it quite like that) for packaged resale (mind you, that's never stopped some software vendors). But it can export services – quite a lot of high profile eCommerce websites (such as Marks and Spencer) may be repackaged, customised Amazon.

I mostly attended the SOA track and Dan Pritchett, an eBay Technical Fellow, provided some interesting insights here, including the worrying possibility of deadlock between SOA services. Remember “deadly embrace”? And, for instance, “scalability is just a design problem” (it helps if you design for manageability and monitoring, of course) - but what really keeps him awake at night is large scale testing and large scale software and content deployment (if it does go wrong, how on earth do you roll back). Again, it's a cultural thing, eBay rather makes a fetish of “no single point of failure”. He also pointed out that power consumption and cooling are now a primary constraint to growth at eBay.

Burton Group Analyst Anne Thomas-Manes gave an interesting talk on bridging business and technology with SOA. She suggested that SOA must be a business initiative, that it needs a new perspective on IT and that it probably shouldn't be run from the IT group. She emphasised that you shouldn't try to sell SOA to an unreceptive audience but that a “stealth SOA” introduction can work (although it will take longer) if you can demonstrate value as you go.

But remember that SOA is not applications-focused, although funding often is (and this may lead to political issues). A SOA service should implement a discrete piece of functionality that is “consumed by” (not reused by) many applications – think of a database, not a reusable code module, as a service. And you shouldn't ask a vendor to sell you “SOA”; although if you do, most will be happy to sell you ESB technology – even though SOA isn't about technology, it's about the business.

There were some deeply interactive sessions around SOAP v. REST etc., which didn't quite descend into fisticuffs, but I think everyone had an exciting time. I was left in no doubt that there isn't one “right” answer to all this – although a strong case was made for encapsulation (“keeping secrets”) as a universal Good Thing.

QCon's sponsors included Thoughtworks, and there was a definite Agile feel to the whole thing. Martin Fowler, with Dan North, delivered an agile keynote on “The Yawning Crevasse of Doom”devoted to the importance of communication between those developing software and those who benefit from it (users and customers). Fowler stressed the importance of the bridge metaphor, with developers and users able to physically mingle on one or another side of the crevasse instead of tossing things across the gap. Hardly a new idea – and the fact that it still needs to be promulgated, should worry us all.

As so often. I was left with enormous respect for these agile gurus and their insight and self-discipline – and just a little concerned about how “ordinary” undisciplined developers like thee and me will cope. There's “People, Process and Technology” and Agile stresses “People over Process”, but depending on people can be dystopian as well as utopian. A fire-fighting “hero culture” isn't really what we should think of as Agile but I'm not sure that it isn't still popular amongst some technicians – and even their managers (who probably got where they are by being excellent fire-fighters). ®