Martin Fowler Presentation

Martin Fowler & Evan BottcherI had the privilege (along with most of Perth’s Agile community, by the look of it) of seeing Martin Fowler speak at the ThoughtWorks quarterly briefing at the Melbourne Hotel last night. Martin gave two short talks (what he calls a ‘Suite of Talks’), one on Continuous Integration & Continuous Delivery, and one covering his concept of different forms of Technical Debt. None of it was particularly new content to a hypothetical attendee who slavishly pores over everything Martin writes, but he has a great presentation style and connection with the audience, which was really enjoyable.

However, I did want to make a comment on Evan Bottcher’s talk on DevOps. Evan’s presentation was spot-on as far as delivering useful, real-world advice on bridging the gap between separate development & operations teams, but I’ve always found the concept of DevOps quite funny. I’ve spent most of my career in small, in-house teams, where I’ve had the admin passwords to all of the production servers & databases, been responsible for all the deployment, and been the first person that users call when something goes wrong. The idea that DevOps is some sort of ground-breaking paradigm shift in application service delivery is wrong — small teams have been doing it for decades.

Afterwards, I managed to get a few quick words with Martin & shake his hand — it’s great to see speakers of that calibre come to Perth.

2 thoughts on “Martin Fowler Presentation

  1. Interesting point about DevOps. I’ve actually thought something similar about the agile manifesto — I was once working solo developing solutions for a single site, and there were never any big requirements documents dumped on my desk; instead, every project started as a conversation, and proceeded in an iterative fashion with features being frequently demonstrated to the “project owner” (though we didn’t use that term, of course) to get their feedback and further clarify their requirements. Deployment was straightforward, so frequent releases were the norm.

    Looking back, it’s surprising how many of the 12 principles from the agile manifesto just arose quite naturally from this very unstructured process. But it’s also easy for me to see that this WOULD NOT SCALE very easily to larger teams and larger projects. I think that’s why we need techniques like Scrum: to overcome the problems of scaling.

    1. Hi Todd,
      Yes, I think you’re right – the main difference between an Agile project and almost any project run by a competent small team (< 3 people) tends to be the discipline & structure; most of the core practices are very similar. I like to think of Agile as a set of processes & patterns that enable a larger team to simulate the efficiency & effectiveness of a small team, although I suspect many large-team Agile people wouldn’t necessarily see it that way!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s