Martin Fowler in Atlanta - DSLs, Agile, CI

I went to Martin Fowler's talk last night night at the Crowne Plaza Hotel next to Perimeter Mall. Martin Fowler is the Chief Scientist at ThoughtWorks and it has been a great experience to finally hear him speak personally. He have three mini presentations:

His first talk was about domain specific languages (DSL) covering all the different variation of DSLs - external DSLs (XML, custom language) and internal DSLs (e.g Ruby). Martin Fowler also had a slide about Language Workbenches - I saw an article on his website covering that subject, which I need to look at in the next few days.

An interesting point I thought he raised was, to focus on making codified business concerns "readable" through DSLs rather than making the DSL available to business people to write rules, business logic etc. as this would be so much harder to achieve.

In his second presentation segment, Martin Fowler answered questions, that were submitted by the audience prior to his presentation, which covered various aspect of agile software development. He mentioned that the British newspaper The Guardian, is releasing software changes into production every 2 weeks.

The way to achieve this is through total test automation. He mentions that at Thoughtworks manual QA is reduced to exploratory testing and that any test plans etc. are part of the automated build process (More details about this at the end of this blog post)

A popular question these days also seems to be whether Java has peaked and whether also languages shall be considered. Martin Fowler, stated that "Java stalled" but it is not going away. However, he  also pointed to the fact, that you should consider more productive languages (especially for new projects). He mentioned an internal and informal Thoughtworks survey in which developers on average attested a 0.5-2.5x increase in productivety when using alternative languages (Ruby, Groovy, Scala, Clojure etc.). Martin Fowler himself expressed his preference for Ruby.  

His last talk was about continuous integration and continuous delivery. He talked a bit about different approaches regarding managing your source code in your respective source repository (e.g. Subversion). Specifically he talked about having feature branches versus just a single trunk (for the most part). It was interesting to hear him talk about that as at work we recently had that same discussion and we finally settled on having just a single trunk for all our regular development efforts. He said feature branches are just too painful when doing merges.

Moving on, he suggested to commit your code at least once a day, preferably even more often.

He then talked about continuous delivery, meaning to continuously push code into production in a controlled fashion. He mentioned a Suisse Insurances company that would deploy code into production once a day. As far as I remember he said that at Thoughtworks they typically deploy into production every two weeks to once a month.

In order to achieve that you must have really good automated testing at which point Martin Fowler talked about having a "build pipeline" which consists of the following phases:

1. Commit Stage - Build project run tests (unit-tests), execution shouldn't take longer than 10 minutes. Deploy artifacts to artifacts repository
2. Acceptance Stage - Deploy the application, run smoke tests, run acceptance tests. This stage may take much longer (e.g. 1-2 hours)
3. Performance Stage - Run Performance Tests - This may take a very long time
4. Deployment Stage - Deploy the application into production - It is important to be able to deploy by just  pressing one button. However, have a rollback option

Then he talked a little bit about Cruise, Thoughtwork's product to help implement that kind of continuous delivery. There is also a book coming out from Addison Wesley called Continuous Delivery.

That basically conclded his talk - there was one further question from the audience that caught my attention. Chris Curtin (CTO of Silverpop) asked him about the Devops movement. Personally I was unaware of that term. In my understanding, this fairly new concept brings developers and operation teams closer together.

Martin Fowler found that concept to be a very positive thing saying that if a production issue was caused by a developer, he should carry the pager for that and fix it. I have to learn more about the Devops movement - here is an interesting blog entry that seems to summarize it quite well: http://www.jedi.be/blog/2010/02/12/what-is-this-devops-thing-anyway/.

A great evening - learned a lot.