Bug Free Code

For the last two years at Allegro we’ve been working with No Backlog. When I share the experience of this with people they often ask “what about the bugs?” and my response “we don’t have bugs”.On reflection this sounds really conceited!I don’t mean that I write perfect, bug free code.I’m not saying I get all of the features 100% right for the user every time.I’m not saying I think about every scenario and permutation of the journey.

I’m simply saying “we don’t have bugs.”. That’s our mindset for the entire project. Working with a greenfield project has given me the luxury of being able to adopt the from the outset and experiment.

We test first. This way we have full confidence that the user journey, or our understanding of it, is not only documented, but is tested for every commit (there is an issue here with feedback cycles, but it’s an interesting problem and another blog post!!).

We continuously deploy, which means we commit very frequently (every line change usually) and the code is always in a working state. This means that as soon as a bug is found, we can stop what we’re doing and fix the problem immediately. Of course we add a test to ensure the bug doesn’t come back. Then we can go back to what we were working on.

We have no backlog.

Because we haven’t let our amount of work build up, and we are constantly prioritising what’s the most important thing to work on right now, there’s no scrabbling for development time, where the shiney new, value adding features take precedence over non-value adding bug fixing. By constantly delivering, being able to move quickly and change direction, we’ve gained trust with the team that the important stuff will keep coming up and when it’s the right time we’ll get it out the door quickly and as right as possible as we are so close to the stakeholders we can have conversations and re-adjust what we’re working on as we go along.

So when I say we don’t have bugs, I really mean we don’t have bugs.