At the end of the 1990's I made a personal push-back against using slides in presentations, as I was tired by poorly designed bullet-points presentations. For around a decade, I gave keynotes with no slides at all. In the last year or so I've started using slides again - primarily inspired by watching my colleague Neal Ford who turns the dreaded slide-deck into a genuine enhancement to his talks (and is collaborating on a book project to pass on his techniques). As I've been working with slides again, I've also been thinking about what makes a set of slides an effective part of a talk. Thee main principle I've tried to follow is to think of them as a visual channel that complements the audio channel which is my spoken words. I find that thinking them of separate channels in this way helps me avoid common problems with presentations - many of which are rooted in the commonplace bullet point slides.

One of the prevailing assumptions that fans of Continuous Integration have is that builds should be reproducible. By this we mean that at any point you should be able to take some older version of the system that you are working on and build it from source in exactly the same way as you did then.

As I've been using slides again as a visual channel in my talks, I've been making use of animation with diagrams to help communicate my points. The major presentation programs (Keynote and Powerpoint) have long supported animation, but I've been inclinded to look for motion grahics tools that are more powerful and easier to use.

I've been intending to upgrade my laptop to Snow Leopard for ages. Particularly once I got Aperture 3, which I'm told works better. But I never quite got around to it, after all operating system upgrades are usually such a pain. (Although Ubuntu upgrades are much less painful than most.)

An interview with Jez Humble and me at QCon San Francisco in 2010

One of the most common arguments in favor of FeatureBranch is that it provides a mechanism for pending features that take longer than a single release cycle. Imagine you are releasing into production every two weeks, but need to build a feature that's going to take three months to complete. How do you use Continuous Integration to keep everyone working on the mainline without revealing a half-implemented feature on your releases? We run into this issue quite a lot and feature flags are a handy tool to deal with it.

Scattered impressions from my recent trip to Australia for the Agile Australia conference.

Last week I attended the Agile 2010 conference in Orlando. Agile 20xx is the major US agile-oriented conference whose roots go back to XP Universe and the Agile Development Conference. I've not been a regular attender of the main agile conferences, but I did go last year as well. Rather than make an attempt at a consolidated description, here are a few scattered impressions.

One of the steady themes I've seen throughout my career is that of the nature and importance of software development. A few years ago a prospect told one of our salespeople that “software is like sewage pipes, I want it to work reliably and I don't want to know about the details”. This is the kind of approach that Nicholas Carr talked about in IT Doesn't Matter. On a contrasting note we've done work for many businesses where IT has been a clearer strategic enabler to their business, allowing them to enter new markets or significantly increase their market share. So is IT a utility, like sewage pipes, or a strategic asset?

A common thing you find in agile projects is that the development team sits in a single open team room. It was advocated early on in Extreme Programming and called out as one of primary practices in the second edition. Agilists favor a open team room as it promotes lots of informal and deep communication between people on the team.

The default layout of workstations in a TeamRoom is a central desk, with everyone sitting around it. However a number of my colleagues now prefer a u-pod, with developers in the middle of a U shape of tables.

I've not seen myself as an iFanboy. I didn't get an iPhone for ages after it came out, and only got one because it was the only way to upgrade my data plan to 3G. I use a mac, but I also have an Ubuntu desktop. But I have got an iPad, and I think it's a significant product.

Interview with Paulo Caroli and me at Agile Brazil

Neal Ford and I gave a talk at USI in Paris (2010) on some aspects of why agile works (as opposed to how). This probes at some of the core forces that makes agile effective, rather than looking at techniques. In particular we look at role of communication and feedback and how they interplay in agile environments.

Like many obsessive snappers, I've recently got hold of the Canon S90 camera. It's small enough to fit in your pocket, but has the kind of things that people with pretensions to seriousness like: full manual controls, RAW file support, a good sensor, and an f2 lens.

I recently needed to stay at a Heathrow airport hotel in order to make an early flight. A big annoyance of doing this is the difficulty of getting from a hotel to the airport. There are plenty of hotels that are just half a mile from the terminal 1-3 centre, but to get to them you have to use the Heathrow Hoppa bus service. This isn't a bad service, but is apallingly expensive: 4 UK pounds, each way, for a journey of half a mile. A half-mile is an easy walk, so I really balk at using a bus, let alone one that charges such a ridiculous fee. Fortunately there's an alternative, although Heathrow makes it hard to find.

During the last fifteen years or so, I've given a lot of keynote talks. I've always found these kinds of talks rather awkward. If you give a talk during a session at a conference, you pick one subject to talk about. You know that there's multiple tracks, so if people come to your talk that implies a certain amount of interest in your topic. But with keynotes you're speaking to the whole conference, so I feel I can't make my talk too tightly focused. I may like talking about the intricacies of modeling temporal events, but I feel that that's too narrow a topic for a broad ranged audience

SEMAT (Software Engineering Method and Theory) is an effort initiated by Ivar Jacobson, Bertrand Meyer, and Richard Soley. Its stated aim is to “refound software engineering based on a solid theory, proven principles and best practices”. Like many notorious people in the software world I was invited to participate. Thus far I've declined and feel the need to explain why.

We've just returned from a week's vacation on the Amalfi Coast of Italy. For those contemplating a similar trip, here are a few scattered impressions.

A model (developed by Leonard Richardson) that breaks down the principal elements of a REST approach into three steps. These introduce resources, http verbs, and hypermedia controls.

When I discussed VersionControlTools I said that it was an unscientific agglomeration of opinion. As I was doing it I realized that I could add some spurious but mesmerizing numbers to my analysis by doing a survey. Google's spreadsheet makes the mechanics of conducting a survey really simple, so I couldn't resist.

One of the arguments used to support the adoption of lean techniques in software is the success of Toyota. So do Toyota's recent quality failings undermine the case for lean software development?

One of the goals that my colleagues and I urge on our clients is that of a completely automated deployment process. Automating your deployment helps reduce the frictions and delays that crop up in between getting the software “done” and getting it to realize its value. Dave Farley and Jez Humble are finishing up a book on this topic - Continuous Delivery. It builds upon many of the ideas that are commonly associated with Continuous Integration, driving more towards this ability to rapidly put software into production and get it doing something. Their section on blue-green deployment caught my eye as one of those techniques that's underused, so I thought I'd give a brief overview of it here.

If you spend time talking to software developers about tools, one of the biggest topics I hear about are version control tools. Once you've got to the point of using version control tools, and any competent developers does, then they become a big part of your life. Version tools are not just important for maintaining a history of a project, they are also the foundation for a team to collaborate. So it's no surprise that I hear frequent complaints about poor version control tools. In our recent Thoughtworks technology radar, we called out two items as version control tools that enterprises should be assessing for use: Subversion and Distributed Version Control Systems (DVCS). Here I want to expand on that, summarizing many discussions we've had internally about version control tools.

Here's a common misconception about agile methods. It centers on the way user stories are created and flow through the development activity. The misconception is that the product owner (or business analysts) creates user stories and then put them in front of developers to implement. The notion is that this is a flow from product owner to development, with the product owner responsible for determining what needs to be done and the developers how to do it.

An approach where stories are written by product owners or analysts and passed to developers to build. I see this as a profound misunderstanding of agile thinking and thus greatly prefer ConversationalStories.