Saturday, 3 January 2015

2014 Retrospective

At the end of 2012 I performed a simple Retrospective of the year.  I seem to have neglected to do one at the end of 2013 but it shall be a yearly habit from now on.


Conferences attended:


Presentations:



Published:

This is a big achievement for me personally.  Thank you to those that made it happen.

  • Joint Contributor with Paul Shannon in More Agile Testing by Lisa Crispin and Janet Gregory
  • Contributed a chapter to Build Quality In - the collection of Continuous Delivery and DevOps stories edited by Steve Smith and Matthew Skelton


Personal:

  • Co-organised my first conference - PIPELINE 2014!
  • Went skiing for the first time
  • Started Portuguese lessons
  • Took Cycling Classes and Bicycle Maintenance classes
  • Continued my Cello lessons (aiming for Grade 3 this spring)
  • Attempted the Computer Networks Coursera course and achieved a grade of 47%. I'm proud of this score as it was a pretty intense course.
  • Stepped down from the ACCU committee as I could no longer devote the proper time to it.
  • Only managed to finish reading 6 books when I'd hoped to read 18.
  • Donated blood 3 times before being temporarily suspended to investigate anaemia :(
  • Sadly, I still have limited proficiency with the Portuguese language

Changed Jobs
In August I left my role at 7digital, I job and company I loved and spoke about, after 4 years of being with them.  I wanted to try a new challenge.  I know it sounds corny, but I really did.  I wanted to see if I could take all the things I'd learned there to somewhere new, share my knowledfe and learn even more.

I took up a Senior Engineer role at JUST EAT and it's been great.  I've had much to learn and as a result have been battling my own Imposter Syndrome, but I hope I've been making a difference, even a small one.

Next Year

I plan to get back on top of my reading, blogging and neglected fitness - the usual stuff.

Having left 7digital in August I now longer feel comfortable presenting about the experience report about their journey towards Continuous Delivery.  Change happens there every day and I am no longer able to 'finish' the presentation with details of what is currently being achieved.  There are still many things I could talk about from that time though, possibly distil the learnings into something more transferable, but I believe the audiences enjoyed hearing a real life experience report.

Creating a new presentation is top of the list and I'm open to ideas and suggestions.

Conclusion

Once again I've achieved more than I thought - a year is a long time and we regularly fail to remember anything other than recent events.  This feeling has been compounded by my focus in the latter half of the year being centred almost exclusively on my new role at JUST EAT, which is to be expected.  A new role is challenging with a new codebase, domain, terminology and people to learn about, which is exactly what I was seeking, so I'm happy!

Here's to 2015!

Thursday, 1 January 2015

Frequent releases reduce risk

This post expands on a train of thought initiated by Dan North in his talk "Kicking the Complexity Habit" at NDC London 2014.

"Frequent releases reduce risk" - this is something you hear all the time in conversations about Continuous Delivery.  How exactly is this the case?  It sounds counter-intuitive.  Surely releasing more often is introducing more volatility into Production? Isn't it less risky to hold off releasing as long as possible and take your time with testing to guarantee confidence in the package?

Let's think about what we mean by risk.

What is risk?

Risk is a factor of the likelihood of a failure happening combined with the worst case impact of that failure:

Risk = Likelihood of failure x Worst case impact of failure

Therefore an extremely low risk activity is when failure is incredibly unlikely to happen and the impact of the failure is negligible.  Low risk activities also include those where either of these factors is remarkably low such that it severely reduces the effect of the other.

Playing the lottery is low risk - the chance of failing (i.e. not winning) is very high, but the impact of failing (i.e. losing the cost of the ticket) is minimal, hence why many people play the lottery.

Flying is also low risk due to the factors being balanced the opposite way. The chance of a failure is extremely low - flying has a very high safety record - but the impact of a failure is extremely high.  We fly often as we consider the risk to be very low.

High risk activities are when both sides of the ratio are high - high likelihood of failure and high impact, for example extreme sports such as free solo climbing and cave diving.

Large, infrequent releases are riskier

Rolling a set of changes into a single release package increases the likelihood of a failure occurring - a lot of change is happening all at once.   

The worst case impact of a failure includes the release causing an outage and severe data loss.  Each change in a release could cause this to happen.  

The reaction to try and test for every failure is a reasonable one, but it is impossible.  We can test for the known scenarios but we can't test for scenarios we don't know about until they are encountered ("unknown unknowns").   This is not to say that testing is pointless, on the contrary it provides confidence that the changes have not broken expected, known, behaviour.  The tricky part is balancing the desire for thorough testing against the likelihood of them finding a failure and the time taken to perform and maintain them.

Build up an automated suite of tests which protect against the failure scenarios you know about, and each time a new one is encountered add it to the test suite.  Increase your suite of regressions tests, but keep them light, fast and repeatable.  

No matter how much you test, Production is the only place where it counts.

Small, frequent releases reduce the likelihood of a failure

Releasing often, containing as small a change as possible, reduces the likelihood that the release will contain a failure.

There's no way to reduce the impact of a failure - the worst case is still that the release could bring the whole system down and incur severe data loss, but we lower the overall risk with the smaller releases.

Release small changes often and reduce the likelihood of a failure and therefore the risk.

Saturday, 14 June 2014

Book - "Build Quality In"


I'm extremely happy to announce that I've been asked to contribute to a new book about Continuous Delivery and DevOps called "Build Quality In".  The book is being collated and edited by my LondonCD and PIPELINE conf colleagues Steve Smith and Matthew Skelton.  We're going to be donating 70% of author royalties to the awesome initiative Code Club as our way of giving back.
It's going to be a collection of experience reports, including the successes and failures of many teams and projects - there will be much to share and learn!  
The book will be released continuously (hah!) via LeanPub and you can register your interest here: https://leanpub.com/buildqualityin

Sunday, 4 May 2014

Versioning


Versioning is hard, so why do we do it?  To enable consuming apps to resist change.

What if these apps were built to be tolerant of change? What if you built your API or library in such a way that you avoided breaking the contract, but added to it? What if you constantly push changes and consumers constantly consume them?

What would you need versioning for now?

Tuesday, 18 February 2014

Gotcha when downgrading ServiceStack.Redis to version 3

Update

It turns out that this is caused by a change of the default behaviour in NuGet 2.8 whereby it now picks the lowest patch version of a package dependency.

 ----

You're probably aware of the announcement that ServiceStack is no longer free from version 4, but if you've already installed it, and reflexively clicked the licence agreement, then you probably need to downgrade to the latest of v3.

I discovered the hard way that there's a mismatch in the versions pulled down from NuGet.  Cryptically, this gives the following error message:

System.TypeLoadException : Method 'get_Db' in type 'ServiceStack.Redis.RedisNativeClient' from assembly 'ServiceStack.Redis, Version=3.9.71.0, Culture=neutral, PublicKeyToken=null' does not have an implementation.

If you run the command Install-Package ServiceStack.Redis -Version 3.9.71 then along with ServiceStack.Redis v3.9.71 NuGet pulls down ServiceStack.Common version 3.9.11, which is not compatible (I've confirmed this behaviour in a fresh solution).

To solve it, you need to explicitly install version 3.9.71 of ServiceStack.Common:

Install-Package ServiceStack.Common -Version 3.9.71

P.s. don't forget to set the version constraints in your package.config file.

Wednesday, 13 November 2013

Islington STEM Event

We're constantly hearing about the skills shortage for IT roles in the UK Technology Industry and how more female role models are needed to encourage young women to consider IT careers.  Last year I decided I would get involved and signed myself up to be a STEM Ambassador.  STEM is an acronym for Science Technology Engineering and Maths which is generally used in the world of education.

On Monday I took part in a STEM Careers event for Year 9 pupils (13-14 year olds) held at the City and Islington Sixth Form College.  I was a Speed Networker, along with Ambassadors from other STEM fields.  The format entails having the Ambassadors sit at separate tables and the pupils get to spend 5 minutes at each one before moving onto another table.

It was suggested that I bring a prop with me from my job, so I grabbed a laptop.  Now this is the second time I've done an event like this and I learned the hard way that showing a screen of code to young people does not impress them, rather it frightens them.  They find the code impenetrable, they assume it's complex and don't even look at it.  I did have some success showing HTML to students and saw the lights go on when they discovered it was easily understandable.


This time I loaded up my presentation for A Day in the Life of a 7digital Developer so that I could show the images of the office, the daily standup, people pair programming and other pictures.  I also showed my spike I did with WebGL a couple of years ago as I discovered that something visual can capture their imaginations.

Almost all of the pupils had no knowledge of what a Software Developer does, or even what the role is.  I tried to get across the feeling of creativity and exploration that comes with being able to develop software whilst  also emphasising the need for teamwork inherent in the role.  In the space of 5 minutes it was impossible, but I hope that my enthusiasm came across and that  alone will inspire them to look into it as a choice.

It was an interesting day, and very tiring, but I feel that we made a difference in giving the pupils a chance to meet real people in different STEM roles and expand their knowledge of the opportunities out there.



Tuesday, 17 September 2013

Agile on the Beach - Day 2

After the first day of Agile on the Beach I had a restful sleep in the excellent student accommodation.  The next morning started with a tasty English breakfast provided by the campus kitchens.

The second day of the event was kicked off with a second keynote speaker, Gabriel Steinhardt, about his take on Marketing Driven Product Management.  The talk started off very well, with an overview and definition of the Product Owner role and where Gabriel sees it fitting into product development - it is indeed true that in many places the role lacks definition.

http://agileonthebeach.com/2013-programme/2013-photos/img_3368/
Gabriel then spent some time discussing where the role fits in a classic hierarchical company structure, followed by what seemed like advocating for the Software Development Team to be removed as much as possible from clients and even decision making related to the product.  This all felt a bit too "command and control" for my liking - he seemed overly concerned with putting people into boxes.  It was at this point that his talk began to become controversial - in an agile conference with a stream aimed at Developers and another at Teams, his points felt incongruent to the overall feel.  Though, as Alan Kelly stated, a controversial keynote is an excellent way to get people thinking. It's good to break the effect of the echo chamber now and then, and I appreciated Gabriel's points about Product Owners, but we'll have to disagree on the role Developers should play.

After the Keynote I attended Steve Freeman's talk Fractal TDD. This turned out to be the same talk I had seen presented at Devs in the Ditch. Regardless, as with all forms of learning, repetition is extremely helpful in assimilating new information and I appreciated the recap.
Seb Rose was up next in the Software Craftsmanship track with Good Test, Bad Test.  Seb has six attributes he feels define a good test and he backed these up with examples. A very good talk although I disagree slightly on one or two small things, but these are personal niggles and will need a blog post of their own.

http://agileonthebeach.com/?attachment_id=1110
Lunch was once again a range of sandwiches and a short session by Tanya Krywinska who was appealing to the general community for feedback and suggestions on a range of Games Development degree courses she intends to launch. I felt that some of the audience had forgotten what it was like to be at university as they made statements that the university fees alone should be enough impetuous to fully engage students in group work. I distinctly remember money and fees being a "future problem" that "future me" would resolve (and 10 years later that future is nearly here as my loan dwindles) and group work being something fraught with egos and procrastination.

I suggested regular 1-2-1s to highlight any group issues, although I conceded that this may not be practical. Also, regular demos, as in Scrum, could help maintain focus.

For the rest of the day I decided to leave the Software Craftsmanship track and saw Judith Andersen's talk. This was probably my favourite talk of the event. Judith explained how, when groups grow, they reach certain numbers which cause a change in the dynamics - increased channels of communication, the formation of cliques, etc.  She included her tactics for tackling and overcoming these problems, which are a function of our human nature, and dispelled some myths. The incorrect assumption that talking about feelings is unprofessional being an extremely important one. I highly recommend watching the video.

Finally, I stayed on the Teams track and saw a talk enticingly entitled The "Just Do It" Approach to Change Management. Unfortunately I could not maintain my attention during this presentation. I don't know if this is a reflection on me and how tired I felt or the speakers. They had attempted to do a kind of double act where they bounce jokes off each other, which I always feel is so difficult to get right that it mostly ended up feeling awkward.

All in all, it was a good conference. It was small, friendly and with interesting talks. The organisation was good too - many events forget to add a few minutes between presentations and they soon begin to go off schedule as laptops must be setup and attendees move from room to room.

I would also like to than Alan Kelly who badgered me into submitting my presentation - I honestly didn't think people would consider it worthwhile but I'm happy to have been proven wrong.
I hope to see everyone again next
year on the 5th & 6th September.