OOP Conference is the longest running conferences I’ve ever presented at. This year was it’s 21st year of running, and although coming from Object-Oriented programming roots, the contents of OOPConference have evolved with the times to represent so much more – just like JAOO has over the years.

This is the second conference I’ve presented at where the talks were in a mix of languages – obviously German, since the conference is based in Munich, and the other language being English. As a result, the number of sessions I attended was much lower than I normally would and I was able to catch up with a number of other speakers such as Johanna Rothman, Michael Nygard (author of Release it!), Kevlin Henney (97 Things curator) as well as meeting many new speakers.

I was also surprised at how many German speakers I’d met previously and got to practice a little bit of German. I did try sitting in on one session with a former colleague, Gregor Hohpe where he talked about (auf Deutsch) the Near-Field Communication technology the Japanese have. He talks pretty fast in English, let alone in German. I thought I was doing pretty well understanding the gist, but at probably half an hour into the talk, I think my brain seemed to explode and couldn’t take any more. A good way to test your limits Fortunately he also used lots of photos in the slides so I could follow along.

I attended a number of other talks in English, one on the latest going on in the NoSQL space (reminding me of a news commentary on what was going on) as well as one of the keynotes by David Parnas. I’ll admit that none of the keynotes blew me away. They all had good solid points they wanted to get across but the message not really new to me. I appreciated listening to Parnas’ talk because of his significant impact to the way OO-Programming is done, although his focus on documenting and enforcing contracts meticulously (whilst having its place) isn’t necessarily as relevant in the internet applications of today (but highly relevant in embedded systems that last for 25 years!).

Something I learned from his keynote was a new tool for better thinking about object oriented design, providing a table to help people classify what sort of information they want to hide and some recommendations to do so. Although probably not a very new tool, I think it has been forgotten through the passage of time and I know plenty of developers who could learn more about real encapsulation who’d benefit from it.

I had two sessions presented at OOP Conference. The first, “Learning to see, A Systems Thinking Primer” gave people a focused introduction to systems thinking concepts, the ideas of archetypes and applying it to situations in software. I’m really glad that a German audience proved much more interactive than I’d hope and I think it proved some interesting insights into topics such as Mental Models and such.

The other sesison was working with my Hamburg-based colleague, Ken Fassone on a “Night School” lecture/workshop Pair Programming: Good, Bad and Ugly (which I have to give credit to another colleague, Rachel Laycock for). I’m not sure some some people anticipated a workshop, but I’m pleased at how some people enjoyed it. We swapped exercises after a mishap with some supplies and shipment, but afterwards, realised how difficult it was for some attendees to do some sentence writing, with a new group, in a language that is not their mother tongue. They did way better than I ever could, and from the enthusiastic thanks from some of the participants at the end of the workshop, proved to be an enjoyable exercise as well.

Anyone who knows me will know I enjoy my food. Maybe a bit too much, but that’s besides the point. I’ve seen my fair share of food-related TV shows and love to see the insides of how successful restaurants work. Ramsey’s Kitchen Nightmares showcase great examples of how not to run restaurants and their episodes are just as relevant to software as they are to the food industry. One practice that is common in exemplary restaurants is a daily standup between the entire restaurant staff, usually combining the kitchen staff and front of staff as well. I remember seeing one of these at one of my favourite restaurants in Berlin, Dos Palillos. It was hugely visible because they have an open kitchen on a ground floor with almost floor to ceiling glass windows.

Knowing what they discuss is easy, having insights from these TV shows. Often the group will synchronise on daily specials, on things to be wary of and maybe any special events or offers for the evening. It’s a chance for everyone to bring things up. Without this, you can only imagine some of the problems that ensue.

I was reminded of this yesterday, walking past the newly Michelin-starred restaurant near my place, North Road and seeing their staff having the very same huddle.

Software teams are very similar to restaurants. It’s useless to have a wonderful kitchen staff churning out amazing food if it fails to be delivered hot, or in the appropriate way, just as much as it is having amazing software teams only to fail getting software out to users. Both group’s success relies on a collaborative effort, not just on one person’s skills alone. Maybe you’ll notice this the next time you walk past a well run restaurant.

I just came off my last holiday where I got through reading two books that I wanted to. One of these was the heavy but insightful tome, that I dragged in my suitcase, Continuous Delivery. Before I begin, I should warn you that I work for ThoughtWorks, and that both Jez and Dave (the authors) are and were my colleagues so take this into account with my review.

What I enjoyed

Continuous Delivery is a very practical book that covers a huge range of topics from cover to cover. I feel that they found a good balance between giving just enough advice (and more importantly why) with plenty more references for those who want to find a topic to delve deeply. I felt it really lays down the ground work for many projects (but not all) that need to see the light of day.

I think it’s also great that they not only outlined the practices and tips, but also outlined the principles. It gives the book much more merit and will make sure it stays relevant as tooling and new techniques are invented. On the flip side, they do give enough advice on tooling, and, at least, current up to date advice on how one might achieve things.

I like that the authors expressed their opinons strongly on some of their tooling such as, if you’re going to use a commercial source control system, how it should be used and why, or what the problems with the build process in maven or the limitations of various toolings are.

The book is peppered with war stories. I think I know some of the examples they cite, or at least, heard about it from other people and I think some of them are really strong stories about some of the ways people approach deployment.

What would make it perfect (for me)

I’m not sure if they framed the context of Continuous Delivery enough in terms of the types of applications it’s appropriate for. I know that there’s a current (constant) movement in the startup community of “just putting out there.” I think that is an alternative approach that works for some amount of time (or at least changes some of the testing/feedback process). I think for throw away apps (this one is always hard to judge), it may not be worth investing in the same degree of how much effort you put into the process. I think probably the closest advice but should have been expanded upon was, “be pragmatic about how much you automate.”

One particular headline (out of the very many) grabbed my attention, “Test targets should not fail the build.” After reading that section I think I understood what they meant, but it should have been relabelled, “Failing test targets should not immediately *halt* the build” -> it should still fail the build at the end.

Finally almost all of the chapters, for me, had lots of great advice and in working reaffirmed many of the conversations and thoughts I’ve had over my career. I did find the final chapter about “Risk Management” a bit thin, feeling like it was added at the end and either deserved much more attention or should have been dropped. It felt like it had a different tone, or was written at a different time and couldn’t quite see how it would fit in.

Having said that, these last bits are only minor points in a huge volume of rich information and is essential reading for anyone who cares about their profession.

Putting this into practice

For most of the clients I work on, the clearest and most difficult part of the organisation will be the (im)maturity of the operations side of the organisations. Most are already not set up for success with completely different parallel hierarchies from development and competing goals that go against constant change. I still see this, “last mile” problem being the hardest (at least for me to solve). I am hopeful about the DevOps movement and hope that the IT parts of an organisation can only take it much more seriously. I’m hoping this book shows how more companies can achieve this.