Blog

Tune logging levels in Production without recompiling code

IAP Software Development Practice JournalThis article first appeared in Software Development Practice, Issue 1, published by IAP (ISSN 2050-1455) 

Abstract

When raising log events in code it can be difficult to choose a severity level (such as Error, Warning, etc.) which will be appropriate for Production; moreover, the severity of an event type may need to be changed after the application has been deployed based on experience of running the application. Different environments (Development (Dev), User Acceptance Testing (UAT), Non-Functional Testing (NFT), Production, etc.) may also require different severity levels for testing purposes. We do not want to recompile an application just to change log severity levels; therefore, the severity level of all events should be configurable for each application or component, and be decoupled from event-raising code, allowing us to tune the severity without recompiling the code.

A simple way to achieve this power and flexibility is to define a set of known event IDs by using a sparse enumeration (enum in C#, Java, and C++), combined with event-ID-to-severity mappings contained in application configuration, allowing the event to be logged with the appropriate configured severity, and for the severity to be changed easily after deployment.

Continue reading Tune logging levels in Production without recompiling code

GOOS at 7digital – Code Shapes, the Purpose of Tests, and Logging Done Well

I recently went to a Devs in the ‘Ditch meetup at 7digital to hear Chris O’Dell (@ChrisAnnODell) explain 7digital’s journey to Continuous Delivery and Steve Freeman (@sf105) speak on GOOS and system testing. We had some useful discussions on dependency injection and how to use logging well, and Steve’s perspectives on ‘code shapes’ and the purpose of tests were revealing.

Continue reading GOOS at 7digital – Code Shapes, the Purpose of Tests, and Logging Done Well

Icebreaker for Agile Retrospectives – Empathy Snap

I was invited by one of our London dev teams to facilitate their retrospective yesterday. I’m far from an expert in facilitating retros, although I enjoy it, and I find that I learn a huge amount from doing so.

Anyhow, I decided to try out my retro ice-breaker exercise which I call Empathy Snap, the aim of which is not only to discover the important features (‘big hitters’) of the last iteration for each team member, but also to see how well team members are aware of the big hitters of their fellow team members. In this way, aspects of the team dynamic can be explored, and dialogue is opened up in a way which immediately requires consideration of others – a useful starting point for a retrospective.

Empathy Snap works like this:

  1. Each team member gets two index cards and a marker pen.
  2. On the first card they write their name at the top and place this card on the table or hand it to the facilitator.
  3. On the second card, hidden from the others, they write the ‘big hitter’ (good or bad) for them from the last iteration, and keep this hidden from view for the time being.
  4. Once all team members have written their ‘big hitter’, each team member takes a name card from the pile, ensuring they do not have their own name card.
  5. On this card, they write what they think is the ‘big hitter’ for the person whose name is on the card, and keep the card. Essentially, they try to guess what that person has written on their hidden card.
  6. Once all the ‘name cards’ have been completed with a ‘big hitter’, a team member reads out the name of the team member written on the card and their guess at the ‘big hitter’ for that person.
  7. The named person then reads out what their big hitter actually was.
  8. If there is a match, then SNAP!
  9. The exercise continues until all team members have read out their guess and have responded with their actual big hitter

We had one SNAP out of the team of 8 (the red asterisks), but the mismatches also provide very useful insights into the team dynamic:

Empathy-Snap-SNAP  Empathy-Snap-mismatch

The team found it useful, so I think we’ll try it next time too. A variation of the exercise can use separate cards for ‘good’ and ‘bad’ big hitters, so doubling the number of cards, and requiring each team member to decide on a good and a bad thing for the person they are considering.

Update: a version of Empathy Snap is featured in the book Fun Retrospectives by @paulocaroli and @caetano_tchttps://leanpub.com/funretrospectives

Update 2: Steve Carter used Empathy Snap while expanding a team:

https://twitter.com/sweavo/status/524224399420174336

Update 3: Guillaume Charmetant evolved the ‘SNAP’ with a ‘high five’:

Update 4: 2017-05-17 – edited the order of the cards to be Name then Big Hitter following feedback at an agile coaching weekend. This made the exercise clearer for people taking part.

Update 5: the Empathy Snap exercise is included in an academic paper from 2015 (!). See Jovanovic, Milos, Antoni-Lluís Mesquida, and Antònia Mas. 2015. ‘Process Improvement with Retrospective Gaming in Agile Software Development’. In Systems, Software and Services Process Improvement, 287–94. Springer, Cham. doi:10.1007/978-3-319-24647-5_23.

Update 6: in the UK, ‘Snap’ is a children’s card game where you try to match pairs of cards. When you get a match, you shout “SNAP!”.

Continuous Delivery in London – recent events and new Meetup group

The last few months in London have seen a surge in interest in Continuous Delivery by companies wanting to speed up delivery of their web-based software systems. See below for a summary of the events I have been fortunate to be involved with (I know there are many more); if you’re interested in Continuous Delivery and you’re in or close to London, then join the London Continuous Delivery meetup group (#londoncd) and let’s share our experience.

London Continuous Delivery logo - @DaveNolan (logo by @DaveNolan!)

James Betteley: Continuous Delivery using Maven

James Betteley gave a useful talk at BCS on how he used Maven in a Continuous Delivery context alongside Artifactory, Nexus and Sonar. James blogged about using Maven for Continuous Delivery back in February 2012: well worth a read, even if you’re not using the Java+Maven stack.

AKQA

In July, Christopher Marsh of AKQA talked about his company’s success with Continuous Delivery on a London-based project for a large client organisation. They used GO from ThoughtWorks Studios for implementing the deployment pipeline.

7digital

I went to the London offices 7digital for a Devs In The ‘Ditch session last week, where Chris O’Dell explained how they have moved from painful, irregular releases with tightly-coupled code to frequent small releases and a service-oriented approach. The transformation took two years, and they now restrict deployable units to about a day’s worth of work to make deployment easier. GOOS co-author Steve Freeman also gave a useful talk on full-system testing, which is crucial to get right in a Continuous Delivery context.

ThoughtWorks Studios GO 12.3

The ThoughtWorks Studios product team have changed the pricing model with the 12.3 version of their agile release management tool GO: the free Community edition how has feature parity with the pay-for editions, including previously enterprise-y only features such as LDAP and Environments. This means that small teams can make full use of the excellent deployment pipeline features of GO without the price tag. I was always a bit reluctant to recommend using GO before now because the free version was feature-limited, but with all features now available in all editions, I have to say that for modelling and implementing deployment pipelines, there is other no tool which comes close to GO.

WebPerfDays EU 2012

I was fortunate to be able to present at WebPerfDays EU 2012 on how build and deployment shapes software architecture at thetrainline.com [slides] along with Andie and Oddur from CCPGames. Three of the many really excellent discussions that came up were:

  1. Why you should design your pipelines up front [more on this from me soon…]
  2. How to get real ownership of software (e.g. service/product teams, devs on call, etc.)
  3. Jenkins vs TravisCI vs TW GO for deployment pipeline automation

Slides: How build and deployment shapes software architecture at thetrainline.com

In the end, we had to be ‘evicted’ from the room; we could have gone on discussing for another hour! Apparently, one major UK publisher had nearly 10 staff in the session, and rated it the best session in WebPerfDays. It was so great to be among such brilliant minds and conversions, which led me to…

A London Continuous Delivery meetup group

Based on conversations and discussions at At WebPerfDays it was clear that a London-based meetup group centered on Continuous Delivery would be interesting for quite a few people and organisations.

A few of us agreed to get things off the ground, and we’re now on Meetup.com at London Continuous Delivery (http://www.meetup.com/London-Continuous-Delivery/) and on Twitter with #londoncd. Any help, donations, perks, etc. are very welcome.

How build & deployment shapes software architecture – WebPerfDays 2012

It was a privilege to be part of the first WebPerfDays EU in London on 5th October 2012. Together with the folks from CCPGames, I facilitated a session on Continuous Delivery, opening the discussion with an overview of how build & deployment shapes software architecture at thetrainline.com:

Slides: How build and deployment shapes software architecture at thetrainline.com

The Continuous Delivery session prompted some excellent discussions around CD; there seems to be interest in setting up a London-based meetup, which I agreed to help coordinate.

Kudos to Steve Thair (@TheOpsMgr) and team for organizing such an excellent event.