Software Quality made this talk happen: push-to-deploy as the means to deal with uncertainty

Slides for my talk

• Markdown
• Interactive

Abstract

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.

The three main takeaways are:

1. Prioritize writing good quality software that rarely breaks. This allows for better work-life balance and frees up time for self-development and community initiatives.
2. Utilize Test-Driven Development (TDD) with a focus on outside-in testing. This builds confidence in code changes and keeps the focus on delivering value to the user.
3. Focus on user stories when building products. This ensures collaboration with all stakeholders and fosters a successful software development process.

This talk would be an encouragement for developers to trust their skills and tools, but also invest in mastering them. On the other hand we as developers often strive for the perfect, beautiful solution; for this approach to succeed we need to embrace imperfect solutions because they provide valuable insight much earlier than most often believe.

Viewing

An up-to-date version is published to GitHub pages.

Press s to show the speaker notes.

Locally

Open the project using Dev Container.

Open two shells:

1. npm run watch
2. npm start

You can now view the slides at http://127.0.0.1:8000.

Building

Render to reveal.js:

make build

Render to PowerPoint (useful for copying to a PowerPoint template):

make public/slides.pptx