A zero bug policy - how to get there? (2/n)

In the previous post, I discussed the reasons for a a zero bug policy using a real example policy. I used a similar approach in teams developing mobile applications, embedded software for public transport, or administrative tools for a utility provider. This post adds the journey to get to a zero bug policy. Introducing a zero bug policy is not always easy, and the start might be a bumpy road. [Read More]

A zero bug policy (1/n)

A critical decision to make when developing software is how to handle bugs. Yet, many teams struggle to cope with bugs effectively and focus mostly on releasing new features quickly. By following a zero bug policy -where bugs take priority over new features- you build in quality. And you avoid a lot of frustration for your users, team members, and management. I write this blog as the first in a series about a zero bug policy to share my experiences. [Read More]

Code katas for selecting technical talent

Code katas for selecting technical talent - An experience report Hiring good technical people for your team is always a challenge. I have experimented with several different approaches in the last few years, from screening CV, in-person interviews, including technical questions, a design challenge to solve a business problem during an interview, etc. But I was never entirely happy with the results because none of these techniques gave me a good indication that the candidate masters good technical practices. [Read More]

Trunk-based development

Trunk-based development When it comes to software delivery speed and quality, trunk-based development is the way to go. It took me a while to realize this myself. I used feature branches with pull-request as the main way of working (writeup of an experience of using pull request), so well aware of the advantages and disadvantages. But switching to Trunk based development felt very counterintuitive to me. For sure, the build would be broken all the time, and the quality would be horrible, especially with a larger group of people? [Read More]

Organizing architectural katas

Architectural katas are a great way to spice up the architectural skills of your team or community, and practice to have productive discussions about architecture. I always receive great feedback after (co)-organizing architectural katas 1 and I regularly get questions on organizing them with others. So with Matteo Pierro, I did run a session at XP-days Benelux 2019 on how you can organize these katas yourself, sharing experiences to encourage others organizing the same kind of katas. [Read More]

Why and how do we use pull requests

The goal of this post is to share why teams I worked with used pull requests and how this was practically organized. Please note that I’m strongly in favor of using trunk-based development over pull requests, and I collected references to get you started in another post. But I still share experience, knowing it’s not a perfect example, as it might provide inspiration on the advantages and disadvantages of such an approach. [Read More]