How and why to run internal tech conferences – InfoQ article

In an environment of rapidly-changing technology and approaches, an internal tech conference can be a powerful and effective way of spreading new ideas and practices and sharing learning & experience. Having organised and run several internal tech conferences (at different organisations), Victoria Morgan-Smith and I decided to write about our experiences in an article for InfoQ: Internal Tech Conferences – How and Why. We also interviewed several other people from various organisations who have also run internal tech conferences in order to give a broader perspective.

Our aim was to inspire and enable other people to develop and run internal tech conferences in their own organisations, building on the experiences of the teams and organisations in the article.

In this article we draw on our personal experience of running internal tech events at companies we’ve worked with, along with reflections and advice from people at Paddy Power Betfair, Callcredit Information Group, ING and others. You’ll find further reading & listening material at the end of the article – there is so much inspirational work happening in so many organisations.

1

Key points from the article are:

  • Software engineering today is as much about people as the technology itself: an internal tech conference can give a huge boost to your organisation’s social capital – that currency by which relationships flourish.
  • The format you choose for your internal tech conference depends on what you want to achieve from it: it can be “by the people for the people”, or a showcase to celebrate achievement. You can keep the audience or speakers to just a single department, or invite other divisions, or even invite external speakers and/or audience.
  • Making the event a success takes effort: choose your speakers well, and mentor themas they prepare their talks. Work on the logistics – it’s the little things that count.
  • Remember to have fun: ‘death by PowerPoint’ will mean people remember the event for the wrong reasons!
  • Follow through: for a lasting impact, keep sight of the outcomes you seek and be ready to work with others to keep the momentum going.

We hope that the article is useful for people thinking of running or improving their own internal tech conferences!

Thanks to everyone involved: people we interviewed, the amazing InfoQ team, and to my co-author Victoria Morgan-Smith.

Notes on ‘team responsibilities in cloud-native operations’ (Pete Mounce)

Summary:  Pete Mounce (@petemounce) from Just Eat gave a compelling talk at the London Continuous Delivery meetup group on ‘team responsibilities in cloud-native operations’. I found the talk hugely engaging, with loads of detail applicable to many organisations. Here are my notes from the meetup.

I captured my notes as slides:

Update: the video of Pete’s talk is here on Vimeo:

Pete Mounce video frame

There were several specific points made by Pete that were interesting for me:

Continue reading

HP is trying to patent Continuous Delivery – here is how you can help block this madness

Summary: Hewlett-Packard (HP) has filed several patents covering standard Continuous Delivery (CD) practices. You can help to have these patents revoked by providing ‘prior art’ examples on Stack Exchange.

On 1st March 2015 I discovered that in 2012 HP had filed a patent (WO2014027990) with the USPO for ‘Performance tests in a continuous deployment pipeline‘ (the patent was granted published in 2014). The exact search I used was https://www.google.co.uk/webhp?q=performance+testing++in+a+pipeline and the patent grabbed my attention almost immediately as it was around the 5th result (as I write this, it still is):

Search results for performance testing in a pipeline

I immediately tweeted and @-mentioned Jez Humble (@jezhumble) and Dave Farley (@davefarley77), co-authors of the foundational book Continuous Delivery, to alert them (their book was published in 2010, two years before the HP patents were filed).

My friend and colleague Steve Smith (@agilestevesmith) quickly created a ‘prior art’ request on the Ask Patents Stack Exchange site to coordinate the collection of references to prior art, so that we have a coordinated place to document the many existing examples of running performance tests in a deployment pipeline prior to the patent being filed. This will help us to refute this patent (WO2014027990). As of today (6th March 2015) the Ask Patents page and various Twitter threads had contributions from several early proponents of CD including Chris Read, Dan North, Jez Humble, Dave Farley, Pat Kua, Andreas Grabner, Erik Doernenburg, and Martin Fowler (amongst others).

The plot thickens

As the “WTF?!” spread on Twitter, Marco Abis (@capotribu) pointed out that not only were the authors almost literally unknown anywhere else on the internet, but that the same HP authors had filed patents for many more standard CD practices:

Here is a screenshot of the search results as of 6th March:

Patents by Inbar SHANI

For the record, here are the patent reference identifiers for these HP patents covering basic CD practices (alternate references given, and hyperlinks to the Ask Patents pages – I will update this page with links to new Ask Patent pages as they appear):

There may of course be other patents filed by HP covering standard CD practices (see below, Okay, what can I do to help?)

WT-actual-F is HP doing?!

There are two explanations I can think of for what HP is doing here. Either the authors of these patents – collectively Adam SPEKTOR, Inbar SHANI, Yaron Burg, Amichai Nitsan, Sigal MAON, Ilan Shufer, Eli Mordechai, and Lior Manor, all of Hewlett-Packard Development Company, L.P. – have been locked away in a cupboard for the last 10 years and have independently invented terms like ‘deployment pipeline’ and are filing what they believe to be genuine applications for true innovations (in which case, I kind of get it, as I think that deployment pipelines are awesome), or (the more likely explanation in my view) HP is patent trolling in a frankly stupid and disrespectful way.

So what’s the problem?

The ‘inventions’ in the HP patents have been practiced, implemented, and documented by advocates of Continuous Integration and Continuous Delivery for many years prior to 2012, particularly by people at ThoughtWorks but also by people from Atlassian, The Guardian, Dynatrace and many others (details in the Ask Patents page for WO2014027990A1).

For instance, here is extract from an article in Dr. Dobb’s (sadly now moribund) from February 2008 by Steve Haines called Continuous Integration and Performance Testing (examples use the first CI server, CruiseControl):

Now you can add performance tests into the continuous integration process. The most straightforward method is to create a new virtual project in CruiseControl, one that uses the same build script but executes a performance unit-testing target. The following shows the key changes you could make to a copy of Listing One’s project definition:

<project name=”ant-junit-performance-unit-tests”>…<schedule interval=”600″><ant anthome=”apache-ant-1.6.5″buildfile=”projects/${project.name}/build.xml”target=”performance-unit-tests.execute” /></schedule><publishers>

<onsuccess>

<artifactspublisher dest=”artifacts/${project.name}”

dir=”projects/ant-junit/profiling-reports”/>

</onsuccess>

In this case, CruiseControl is configured to check for source updates every five minutes—because performance tests take longer to run, they cannot and should not be run as frequently. In a real-world application, checking hourly is more reasonable.

Not only does the article describe the concept of running performance tests as part of CI, but it also shows how; we are also shown how to collect the results, using JMeter:

Once integrated, you define a JMeter Ant task by adding the following to the Ant script:

 <taskdef name=”jmeter”classname=”org.programmerplanet.ant.taskdefs.jmeter.JMeterTask”/>

This is a clear example of prior art. For nearly 40 years Dr. Dobb’s Journal was one of the foremost software magazines in the world (I remember in the late 1990s tentatively reading my first Dr. Dobb’s articles on sorting algorithms and mutexes, and realising how relevant Dr. Dobb’s seemed). There is no excuse for the HP people for missing this kind of prior art when it was so readily available.

To me the patents filed by HP feel like a ‘land grab’ by a company that is struggling to be relevant in the world of Continuous Delivery, with old-skool application release automation (ARA) tools simply rebranded as ‘Continuous Delivery’ (incidentally, may the gods help anyone who pays for these soul-destroying HP tools).

Okay, so what can I do to help?

For each of the patents above we need examples of prior art before 2012: articles, blog posts, conference talks, book chapters, etc. If a patent does not have an Ask Patent page, please create an Ask Patents page (the easiest way to do this is via Google – search for the patent code). Then post the relevant details on the Ask Patents page for the specific patent.

You can also search for other patents from HP relating to CD – perhaps using a different author name (the patents above all relate to Inbar Shani only).

Together let us get the patents overturned through decent prior art details and stop this madness. From the start Continuous Delivery has been a practitioner- and community-led endeavour (with generous guidance from ThoughtWorks). CD is not the place for large behemoth corporations like HP to muscle in and take ownership. As Dan North puts it:

“Identification of a failed code change” in a build pipeline. As a patent. Really @HP? #getoffmylawn

Footnote

Thanks to everyone who helped to spread the word about this, in particular Steve Smith, Dan North, Marco Abis, Pushpak Singh, and all who have added prior art details to the Ask Patents page and contributed to the Twitter WTF stream.

Updates

  1. Corrected ‘granted’ to ‘published’ in first main paragraph. (2015-03-08)

Continuous Delivery eBook from Zend – views from 29 authors

I was recently asked to contribute to an eBook from Zend about moving to Continuous Delivery (CD). The 29 authors in the book share a wide range of experience with CD, and there is plenty of useful advice;  the contributions from Mathias Meyer (@roidrage), Kate Matsudaira (@katemats), and Jamie Ingilby (@jamiei) are particularly worth reading, I think.

In my section of the book I explain how using ThoughtWorks GO to model the testing and release steps (effectively part of the value stream) we won trust from several different people and teams during a move to CD. Using a prototype also helped us to validate the activities undertaken:

We tried to empathize with their situation and, using role-based security in the deployment pipeline, uncovered enough information to give them a sense of visibility and control.

Without being able to visualise and communicate easily the activities we were automating, progress would have been slow or even blocked.

Get a free copy of the eBook here: http://bit.ly/ZendCDbook

Zend eBook CD

The most common DevOps adoption mistake, and other answers – interview for DevOpsFriday5

I was interviewed recently by the folks at Ranger4 for their #DevOpsFriday5 question series. Since  June 2014 (when I was interviewed) I have published a couple of things which expand on the original answers, so I have outlined these here.  The questions were:

  1. What’s your preferred definition of DevOps?
  2. When people ‘do’ DevOps, what’s the most common mistake you see them make?
  3. How do you recommend an organisation new to DevOps start?
  4. What’s your prediction for what DevOps will look like in 2020?
  5. Where do you like to go to get a DevOps hit?

Continue reading

Experience Reports Book on Continuous Delivery and DevOps – ‘Build Quality In’

Cover Image - Build Quality InContinuous Delivery and DevOps are difficult. In many organisations the creation of an automated deployment pipeline is impeded by significant technology challenges, and encouraging Development and Operations teams to work together can seem impossible.

In order to help teams adopt and sustain Continuous Delivery and DevOps, Steve Smith and I decided to put together a book of experience reports – Build Quality In – with contributions from fellow practitioners in these fields.

We have a growing list of really excellent contributors, and we are using LeanPub and its ‘lean’ publication model to make available the content as soon as each chapter is ready – no ‘big bang’ releases! The book is available to buy now on LeanPub, and updates will be made throughout the summer of 2014, with all chapters expected to be ‘done’ by September 2014.

70% of royalties from the book will be donated to the UK non-profit organisation Code Club, which inspires kids to learn how to use computers to build software systems. We wanted to support an organisation that is active in engaging and shaping future engineers (both female and male), and Code Club is doing a great job.

We’re excited to be working with so many talented people on this book, which we hope will become a useful resource for people working in a Continuous Delivery or DevOps context.

Resources

 

DevOps Questions from Unicom DevOps Summit Feb 2014

At the Unicom DevOps Summit event in London on February 28th 2014 we experimented with some extra audience/attendee participation by asking for questions on record cards and encouraged people to ‘dot-vote‘ on the questions most interesting to them. There were some good questions, but unfortunately we did not get chance to discuss many of them, so here are all the questions from the card board, along with some very brief attempts at answers.

  • Should security be a part of DevOps?
  • To what extent and how do you insist on standardisation for multiple Scrum + ‘DevOps’ teams with no separate Operations team?
  • What’s the likely process flow of / disruptions to / duration of DevOps adoption?
  • Where does ‘Operations’ sit in the ITIL model? All over the place? e.g. Service Transition?
  • How about some example scenarios? Tangible comparison points would be useful.
  • Where does DevOps start and finish (from a process perspective)?
  • Is DevOps just a job title?
  • Is co-location of resource necessary for successful DevOps?
  • How essential is cloud technology to DevOps?
  • How will the announcement that ThoughtWorks are ‘open sourcing’ their Go DevOps product affect other vendor products? Why pay for other products?
  • There are a lot of open source DevOps/release/orchestration tools – is anyone using (or know about) the Windows equivalent?
  • How do you overcome developer resistance to writing Run Book docs? Are the processes to drive adoption? Is it a sackable offence?

Continue reading