Forem: Justus Romijn

The zero bug policy: in practice

Justus Romijn — Mon, 21 Mar 2022 07:21:24 +0000

This is a follow up to my original post about implementing a zero-bug-policy. With my team at Rabobank, we've embraced this policy and I want to share our experience from the last year.

A year has passed

We started out with a backlog littered with about 140 bugs. We were aware that a part of those could be closed instantly, for a couple of reasons. Basically it came down to try to reproduce the bug, and if it was not possible, we would log the reason and close it. Some example reasons to close issues were:

bug already fixed (side effect of a refactor, for example)
a duplicated ticket (people don't look for duplicates when reporting, I don't blame them)
the bug context no longer exists (feature removed or changed so the behaviour is gone)

Initial scan

It took some serious effort to go through all these tickets, some of which had been opened years before. But it was really satisfying to be able to close about 40 or so tickets, just because the administration was messy. This left us with something over 100 bugs that were valid.

From many to not so many

About 100 open bugs can still be daunting: how do you ever get to zero? Our goal for each sprint was to at least have less bugs on the backlog than at the start of the sprint. At the end of each sprint, we would log the closed bugs, opened bugs, and the grand total open. During demo's we were transparent about the process so everyone could see how we were doing. It also helps you as a team to have an extra reason to do well on this part: a lot of stakeholders really liked our progress so we really wanted to keep that up!

Example of one of our bug status reports during sprint review

	Major	Minor	Trivial	Total
Open at start	1	2	2	5
New reports	0	1	0	1
Closed	1	1	1	3
Open at end	0	2	1	3

In periods where we had less demand for new features or changes, there was room for specific focus on bug fixing and we were able to get it down with big jumps: this really boosts team morale!

Having zero bugs

Somewhere at the end of last year we finally made it to the zero! It felt as a big achievement, and it had some very positive side effects as well:

less pressure from stakeholders that try to get attention to open issues: we didn't have any!
We jump immediately on new bugs, and because of this we are pretty fast to solve them: if you take on bugs that are still hot from the plate, you can get context and background information very easily, and the reporters are very much willing to help out.
A clear, up-to-date backlog!

Note: Having zero bugs on the backlog does not mean they don't exist: this policy is just meant to take bugs heads on when they are reported.

As a team we really take pride in having no open bugs, and it gives us also peace of mind when shipping new code and working on new features. It also saves much time during planning sessions (bugs always must be picked up) and if a bug is much more trouble or reveals a bigger issue inside, you are very quickly made aware of it.

I'll try to advocate for this policy as much as possible, as my personal experience, as well as that of our team (including our product owner) has been very positive!

The zero bug policy

Justus Romijn — Sun, 04 Apr 2021 17:45:43 +0000

Most software developers that have been around for a while are familiar with the Joel test. Some companies like to show off with a maximum score (12) on this test to attract high profile developers. A lot of best practices that are included in the scoring system are commonplace in the organisations that I've worked for, but I'd like to take a look at item number five.

5: Do you fix bugs before writing new code?

I've never worked somewhere where this question could be answered with "yes", so I'd like to make this practice top of mind again.

The 'Zero Bug Policy' explained

First, let us get a misconception out of the way. The name of this policy is a bit misleading, as writing bug-free code is a myth. Where there is code, there are bugs, no discussion about it.

The policy aims to have zero bugs on your backlog. While doing research on this topic, a couple of different implementations of this policy popped up, but they all share this common goal of a zero bug backlog.

The differences between adaptations are in how to achieve this zero backlog:

Always fix the bug;
Inbox zero style, decide whether:
- it needs to be fixed. Pick up directly;
- it won't be fixed, Close directly;

Do note that bug triage needs to be taken very serious. Often enhancements or originally missing requirements can be brought in as bugs, but make sure to validate it and relabel those issues, to avoid working on bugs that aren't really bugs.

The companies that have embraced the zero bug policy (see sources below), take the inbox zero approach: once a bug comes in, you must decide directly what to do with this: fix or don't fix.

If it is too trivial, or just simply not worth the cost, it is closed as a won't fix, so you never have to look at it again.
If it must be picked up, there are usually only two different types of issues: ones that require immediate attention, which means drop whatever you are doing. Otherwise, fix directly after you've completed your current task.

Where are the gains

By forcing a product to have no known open bugs, a couple of practices are automatically in place, and considerable waste can be removed from the development process.

I like my bugs fresh

Anytime a bug comes in, it immediately requires resolution. An important benefit is that the possible reproduction scenarios, and the person logging the issue are probably quite easy to find, making it way easier to fix this issue. Fresh bugs often also relate to recent changes, so it is easier to backtrack where this issue was introduced. Of course there can be other reasons why new bugs emerge, but it really helps to start on them directly. I'm sure many developers have dealt with an issue that was over an year old. Trying to reproduce it or asking questions about context is basically out of the window, as the original reporter has no clue about it anymore or might even be gone from the company. Maybe the troublesome feature has been rewritten in the meantime, so you don't even know if this even is an issue. Waste, waste, waste.

Avoid the endless backlog

Deferring non-critical bugs to the backlog is a good way to create this huge steaming pile of work that, when being realistic, you will never end up doing. New work tends to always be more important and jumping the line, because of deadlines and promises. During backlog sessions, these open bugs are looked at time and time again, and dragged around while they probably will never be fixed. A big waste.

I can't talk for others, but having a huge steaming pile of open bug reports is a good way to smash motivation as well. For me, it always takes a chunk of mental space, even when I decide to ignore it.

Raise the quality

When bugs are considered an acceptable thing, it can become normal to introduce bugs with new features. Developers can become senseless to bugs.

When having known bugs, and you introduce code that has to deal with the buggy part, it is commonplace to create workarounds or temporary fixes. This is bloat and debt that often is ignored once a bug finally gets resolved. It makes me cringe.

Forcing to work on bugs first shortens the feedback loop on issues with new features. When bugs emerge on new features easily, it means improvements are to be made in the process itself. Why do bugs slip in? You want to look at code reviews, testing and specifications to reduce the chance of introducing new bugs. Being bug-free is an award on its own, and it can help to grow it as a culture.

Become predictable and flexible

Having a bug-free backlog makes you more predictable and gives you more freedom to change focus of work. There is less risk of running into deadlocks, and there is no need for allocated bug-squashing time.

Final notes

I hope this article inspires both developers and Product Owners to give Zero Bug Policy a shot, as I've outlined the benefits. I think it is all about being realistic and draw a clear line where effort goes, and won't go.

At my current employment we are aiming for the Zero Bug Backlog, we are gradually moving towards it and will give it a try to keep it at 0. It has been a stretch to clean everything up, but it felt very similar to when I first adapted Inbox Zero (which meant cleaning up over 1000 emails).

Sources:

What is all that stuff in this frontend repo?

Justus Romijn — Thu, 02 Jul 2020 11:32:28 +0000

Introduction

You are getting ready for your next assignment. Should be an easy job, just update some templates to implement a new menu design, so let's get down to it. Clone this git repo, allright! Wait...wut... what is all this stuff?

My assumption is that a lot of developers have gone through such a moment, where you look a new project in the face and think: what is all this stuff? To help you get back down in your seat again and approach this with some confidence, I will drill down some more common frontend setups that you will encounter anno 2020.

Note: this is (of course) not a full, exhaustive list. Every project is different, and I've seen some rare custom setups over time. This article is aimed to help starting developers to find their way in most projects.

Anatomy of frontend repositories

Files

Independent of framework or type of project, there's going to be a bunch of files in the root folder.

README.md (make a readme)
Always start here. A lot of tools by default open a README file if they find it in the root. Most of the time, this is the best place to find documentation written by the actual maintainers of this project about how to get started, requirements to be able to run it, and possible other details that are relevant.
LICENSE (license help)
Some legal information about usage, warranty and sharing of the code. Also often refer to standard software licenses like MIT, GNU, etc.
package.json (npm docs)
This is also important to peek into. A package.json file indicates that this project relies on the npm ecosystem. Wether or not this project is actually exposed publicly, beside details like name/description/author of this project, it usually also lists dependencies (other packages from npm). Another important aspect is that it often lists a couple of npm scripts that perform certain tasks within a project, like installing dependencies, start a development environment, test the codebase and build/bundle for production. For node projects, the main field in the package.json is rather important as it targets it as the entry point for the package. For website packages, this is not relevant.
package-lock.json (npm docs)
The package lockfile holds metadata about which dependencies were installed in the node_modules. This is very useful to be able to exactly reproduce a specific situation, as by design dependencies are able to be of different version depending on when you run your install command (by allowing patch and minor updates, see semver).
.gitignore (git on gitignore)
This file has instructions of what to exclude from version control. It can be specific files, as well as entire directories. Think about the build-output of your project, temporary folders or dependencies. Common items include node_modules, tmp, dist, www,build and so on.
.editorconfig (editorconfig docs)
To avoid unneeded clashes of handling charactersets and whitespace, this file will help editors pick (among others) tabs vs spaces, level of indentation and how to handle newlines, based on filename/extension.
.[SOMETHING]rc
What exactly is the definition of RC is not entirely clear , but all those RC files are basically configurations for anything that runs in your project and supports it. Often you will find these: .npmrc, .babelrc, etc.
[SOMETHING].config.js [SOMETHING].config.json
Configuration settings for the specified...thing. Think of linters (eslint, prettier), transpilers (babel,traceur), bundlers (rollup,parcel,webpack), typescript (ts), etc.

Folders

node_modules (npm on folders)
All installed dependencies will go in here. Usually this folder is created once you run npm install or yarn install, as it almost always is ignored by git (see .gitignore).
scripts (undocumented convention)
Command line actions from the package.json often refer to executing files in this folder. Building, linting, testing, often the instructions for performing these tasks are in here.
src (undocumented convention)
The real meat: the source code of this project. Probably 90% or more of the repo activity has its place in this folder.
assets (undocumented convention)
Any audio, image, font, video or other static assets are often stored together here.
build|dist (undocumented convention, Stack Overflow question)
The bundled or optimized output of the sourcecode. Depending on the goal of this repo, this may or may not be included in git, so you might have to run some build script first before this will be summoned into existence.
tmp | .tmp (undocumented convention)
When running projects in development mode, it often needs temporary workspace to serve to the browser, it might need intermediate files. Either way, this folder is as it states, temporary. Don't expect it to be there for long.
bin (convention, probably originates in linux and other operating systems)
Any command-line executables are defined here. In the scope of frontend projects, it is mostly limited to some command-line utilities like scaffolding tools (for example generate new pages or components).
lib | vendor (undocumented convention)
Sometimes you need libraries that you cannot, or do not want to rely on through npm. 3th party assets are often stored in this folder.
test (undocumented convention)
For tests that you don't want next to your source code, there is a separate directory. Direct page testing is often something that is written in this folder.

Enjoy your journey

This is just scratching the surface, hopefully this gives beginning developers a clue on what to expect when starting with projects. Basically my advice usually is:

Start with the README! Other maintainers want you to read this first before getting your hands dirty;
Next up: package.json: see what script instructions there are for installation, development, testing and building.
Lets get to it! src: look at how this folder is organised, probably you will start recognising things here and get a clou of how to get things done.

I know that those instructions sound almost blatantly straightforward, but how often did I have someone at my desk asking how to get a project up and running, where I would reply... Did you read the README?

Some follow-up for this could be a repository which holds a lot of those files with comments and readme's, that can be a community-driven effort to explain what it all does in a nice, kind-of interactive way. Let me know in the comments if you would like to see such an initiative!