Catching up

It turns out that having a day job can play havoc with your blogging activities. I’m posting a round-up of recent activities, in no particular order, with the intention of expanding on each of these topics in the coming weeks. But we all know what happens to intentions.

This is mostly a brain dump to make me feel guilty enough to write some of it up, so feel free to skip it if you’re busy. That FaceBook page isn’t going to update itself you know.

Simplicity

At last year’s XP Day in London I got involved in a fishbowl discussion, with the likes of Kevlin Henney among others. Kevlin gets simplicity. To me it’s the holy grail of software development, and it’s all about expressing intent clearly. If you can’t make a system any simpler, then you’re done (simple, not simplistic). Likewise if you can express the intent of an application in a clearer way, you still have work to do. Erik Doernenberg and I shaped this theme into a keynote that I’ll pretend I’m going to write up at some point.

Performance tuning

A couple of years ago I did a performance tuning gig with a major retailer in the US. It was their first foray into J2EE and they were struggling with the impedence mismatch between OO and the relational database. Over the next few weeks I’ll be writing up the various approaches we took to achieve the results we got (startup time down from 10 minutes to 45 seconds, query times down from over 30 minutes to sub-second), because in the intervening period I’ve seen some of the patterns repeating themselves elsewhere.

Agile SOA

I have my “safe” topics that I’m very familiar with presenting: coaching and learning, agile and BDD, various technology topics. Last month I presented outside of my safe zone – on “SOA for Human Beings” at the ExpertZone conference in Stockholm.

SOA is not like the other kids. On one level it’s so vague it’s almost Zen: “What is SOA?” “It’s whatever you want it to be”. Secondly, it’s largely misunderstood as being a technology thing rather than a business thing. Thirdly, it’s often deliberately misrepresented as the reason you have to purchase a particular toolset.

So I stood up in front of the 17 attendees and said: we won’t be discussing code this afternoon – we might not even discuss technology. And we all had a much better afternoon because of it. There were a number of themes that came up during that session, and I’ll try to do them justice in a future article.

Builders, Commands and Fluent Interfaces

I’ve been architecting! You know, like properly designing software on a project as a tech lead. It’s great fun – I’d forgotten how much I liked it. My favourite current toys are builders – in particular fluent interfaces – and the command pattern. Suddenly my world is a simpler and happier place. Come to think of it, I’ve just rolled off a project with Patrick Kua as my tech lead. Talks a lot of sense does Patrick.

BDD in Ruby

Got rbehave out. Phew!

BDD in Java

At some point in the last couple of months, it seems we released JBehave 1.0! It’s been a labour of love, made up of infrequent short bursts of activity interspersed with long periods of day job. Lucky for me, Liz Keogh stepped up and took the reins, and with the help of some other great developers got it to 1.0. I’m very pleased with what we’ve accomplished so far, but there’s plenty more to do. In particular I want to introduce a fluent story builder to remove the need to hand-wire all the stories, and see if we can use some Java 5 goodness to simplicate things.

Real Options

No, not the things traders buy and sell. This is an overlooked branch of mathematics that explains why deferring decisions responsibly is a Good Thing, but deferring them past their “use by” date is just dumb.

My good friend Chris Matts has written an article about real options with Olav Maassen. In a demonstration of the interconnectedness of all things, there are at least two JBehave connections here. Chris was the guy who made the observation that BDD-as-TDD was just like business analysis, which in turn led to the whole story/scenario vocabulary. Olav was the first contributor to JBehave, writing a JBehave Ant task back in 2004. They are both mad as a box of badgers which means the article makes for interesting reading.

3 comments

  1. hi Dan,

    re: performance tuning techniques write-up

    you may find this useful – it’s a write-up of techniques for writing very small programs (disclaimer: by my brother); i’d always thought of it as a curiosity, but it just struck me there are a lot of similiarities with performance tuning:

    http://www.survex.com/~olly/dsm_rheolism/method.html

    cheers, dan.

    1. I only skimmed it but I already like it a lot. I’ll have to look at it in more detail. I particularly like the contrast between “marking” and “hammering”. They are great terms for something that seems to happen a lot with performance tuning. I also like the idea that he is flexible with his metrics. He measures things and then uses the measurements that seem to yield the best subjective improvements. Great stuff!

      1. nice, i’m glad you like it.

        i was thinking a couple of things that seem apparent but might have made the list, more of an outsider’s point of view:

        High Expectations

        you’re only usually going to find a solution somewhere between half-arsed and the upper limit of your expectations – this gives you a lower distribution for final outcome vs. very high expectations of what is possible. (based on they thought they might be able to write tetris in one line)

        Challenge All Assumptions

        i get the feeling they didn’t hold back challenging all aspects – maybe they took this for granted. from my experience, often the biggest breakthoughs are based on this.

        cheers, dan.

Follow

Get every new post delivered to your Inbox.

Join 458 other followers

%d bloggers like this: