I had the great opportunity to attend Qcon from March 7th-9th, an international software development conference held annually. It was such a valuable experience, I took away a lot and heard from inspirational speakers who have influenced innovation and creativity in the engineering world. I wanted to share what I heard from the talks I attended. I will split this post into three so it’s easier to read.
Keynote – Unevenly Distributed by Adrian Colyer
Firstly I would just like to say how great of a speaker Adrian Colyer was! So engaging, great ideas and just overall a brilliant talk and a great start to Qcon. His presentation was based on this idea; the foundation and principles on which the future builds are carefully researched, implemented, evaluated, reviewed and written down. Adrian reads a research paper every (week)day and posts a summary to his blog ‘The Morning Paper‘. I took away these thoughts from his talk:
- What do research papers provide to us? Applied lessons, thinking tools and they raise our expectations
- Is it always the question of ‘the more, the better?’
- The Scalable Commutativity Rule
- The art of testing less without sacrificing quality
- Holistic Configuration Management at Facebook
Continuous Delivery: Benefits explained by Lianping Chen
Lianping Chen works at Paddy Power; they offer betting/gambling services in regulated markets, through shops, phones and mobile apps. He talked about how a few years ago, many releases used to be a scary experience as they were unpredictable and not frequent enough. Delivery activities weren’t efficient, setting up environments could take weeks. Continuous delivery came along, what is it? He recommended the book ‘Continuous Delivery: Reliable Software Releases Through Build, Test and Deployment Automation’.
Continuous Delivery – ‘there is more to continuous delivery than wiring together Jenkins instances and buying a new automated deployment tool’.
- Reliable Releases – less risk, should be another normal day (no stress), deploy at peak times!?, deployment automation to eliminate human errors
- Aligning testing and production environments – saves time on releaes
- Small batches
How do we achieve these things?
- Collaborative culture and organization structure
- Responsibility change – shift responsibility to developers, create trust between teams not friction and avoidance
He said something that stuck with me: ‘DevOps isn’t efficient without automation’. A task that can be done by clicking a button, automate it. Of course you shouldn’t automate tasks that would take more effort to automate and return little value (might as well do it manually). Anyone should be able to click a button!
When you are able to solve these problems, what do you get?
- Accelerated time to market – reduced cycle time from creating a user story to deploying it. Start generating revenue
- Get fast feedback – break big features down so that can be finished in a short period of time
- Better architecture – the architecture should allow adding features in small increments
- Zero-downtime deployments
Some other points
- Testing is not only about writing tests but also about design.
- Improved product quality – customers don’t find bugs, TDD/BDD/ATDD, eliminate flaky (non-deterministic) tests, fixing failing tests is a priority as it means something
- Sonar – for metrics on test coverage
Spending time on writing tests and coming up with elegant design is better than spending time on fixing bugs.
Building the right product
‘You can’t just ask customers what they want and then try to give that to them. By the time you get it built, they’ll want something new’. Steve Jobs
Work on hypotheses, not requirements! i.e. decisions should be based on data, not ‘opinions’
How to win hearts and minds by Chris Young and Kate Gray
This talk was around the topic of how to convince your colleagues when you have an idea/something you want to compare. This talk was packed, had to stand to listen to it! Chris Young and Kate Gray were great speakers. They used the example of electoral politics; i.e. the techniques politicians use when they run campaigns. How can you influence behaviour and decisions? What is the common ground? They described three techniques:
- break down barriers
- creating options
- who is likely to support you?
- you don’t need 100%
- soft support and hard support: there are those who completely support you and understand your cause (hard support) and those that are not too sure if they should support you (soft support). These are the people you need to focus your attention on.
They described this concept of Impact Mapping.
- how do you communicate?
- powerful, persuasive messages
- relevant, meaningful
- emotion over mind, having an effect on people
- ongoing dialect with customers
- keep people in the loop, respect their feedback and ask for their honest opinions
CD at LMAX: Testing into production and back again by Sam Adams
Continuous Delivery does not equal to Continuous Deployment. Continuous delivery is deploying when you have finished development. Continuous deployment is having the ability to deploy when you want.
One of the biggest challenges of going straight from the development environment to production is that the development teams usually do not have access to production environments, due to security reasons. However, for the simple tasks that can be done with a click of a button why don’t we just use automation?
Sam also talked about having tests outside the pipeline (performance, integration, stress) that don’t necessarily block the pipeline but if any issues are identified then these are looked into.
- Everyone ones the test suite
- ‘Intermittency testing’ – the best way to understand a system is to try and fix a problem with it!
- Autotrish – records test results, identifies patterns in failures
- Reliability tests – kill/fail-over/recover suites
- Feature toggles – gradually introduce new features to users by only enabling for one/a few users at a time and then increase the number of users
Acceptance testing for Continuous Delivery by Dave Farley
This talk was given by Dave Farley, one of the writers of the Continuous Delivery book I mentioned above. In this talk he discussed the meaning of acceptance criteria in automated tests.
Firstly, what does ‘done’ mean when you are writing automated tests? This is when the acceptance criteria have been fulfilled and the behaviour outlined has been automated.Acceptance tests should be an executable specification of the system behaviour.
Who owns the tests? This question got me thinking as really, developers, BAs and testers should own the tests. Why is it not only testers? Because developers write code, so they need to own the tests so they know that their code is working and doesn’t break another part of the system in any other way. Because BAs want changes to the system to be made easily and smoothly and so, they should know the test coverage and the value of the tests.
He also talked about what are the tests testing not how they are being tested. By this he meant we should abstract implementations – use mocks, page drivers etc as we are interested in the behaviour when writing acceptance tests, not how it has been implemented.
And last but not least, always use the language of the problem domain for readability and ease of maintenance.