I was first paid to write software in 1997, now 27 years ago, and if there is one skill that had the biggest impact on my career then it’s the ability to deliver working software that doesn’t break. This allows me to take vacation, invest back into my communities and initiatives that I want to support, self-development, and to have time for self-, and family care.

In this talk I want to reinforce your love for software quality by sharing how I helps me in my day to day work where I balance my efforts between too many projects but still manage to be both and innovative software engineer, and deliver solutions that do not break when it matters most through setting up all projects and teams that I work with around one main principle: push-to-deploy.

In order to achieve this, confidence is needed, which can only manifest if we know that our changes will not break the system. And in an environment that becomes more and more uncertain and volatile every day, there is only one solution that has stood the test of time: writing tests first. And its beauty, especially with outside-in-test-driven-development, is that it helps to keep the focus on delivering value to the end-user. Over the last years I have added Behavior-driven development to my quality toolbox because it decouples the implementation of the tests from the implementation of the application. Testing through the public API of a system ensures that there are no unexpected changes for the user.

As I will share, I have a strict focus on user stories when building our products, because it is the only way that ensures that all stakeholders can participate and contribute to a product. Because in the end a successful software is always built in collaboration with people who contribute source-code and those who contribute in other ways.

Enabling the collaboration of all stakeholders is a very important part of my job, and I have been able to achieve this through using a walking skeleton approach: delivering working minimal products from the first day. This way developers like me can make sure to be involved in the discussion with product people and customers early on in a projects' life-cycle. And in my experience only the real product (and not even a click dummy) will truly create shared understanding with all stakeholders. Because time is always short and we know that every prototype ends up in production we have to make sure that even our prototypes are of high quality; which is where using quality in software development to achieve continuous delivery (CD) with confidence - really shine.