Postmortem culture

Things go wrong. This is something that we can try to control, anticipate an plan for. But ultimately we will fail and we won’t be prepared for it. If we consider the amount of interactions we have, the amount of changes by so many people, and the limited amount of resources we have, it should be clear that if we don’t hit some bumps, we’re just going too slow.

One thing that we can do though, is to better handle problems after they happen with a good postmortem culture.

Common project usage: Makefile API

It’s common for me to jump around between projects. For example, I may be working on a backend service and need to jump to a frontend SPA to help the team on some deadline or other specific goal.

But cloning a new project always gives me bad memories. Not being able to run the tests (or not having tests at all), not knowing how to start/run the project (it may have docs for it if I’m lucky). And the worst part: not knowing how to deploy/publish a new version.

First impressions: mutation testing

I was curious about Mutation Testing and the value we can take out of it. So I took an hour to play with it and try to understand it better.

What’s mutation testing?

In mutation testing we have a program that changes our application’s code and then runs the tests. If no tests fails, it means that we may have a problem. In practice this means that we don’t have a full coverage on that code. This is not about the typical 100% code coverage metric. Because we can have some code that is 100% covered and still find problems with mutation testing.

Zero bug policy

Bugs are a tricky subject. We all write code with bugs and they have a considerable impact on our productivity and on the value added by our deliverables. So we come up with several strategies to handle the bug stream and have a ongoing effort to balance bug house keeping and new features.

I’m a big advocate for a zero bug policy. This means that we should usually have 0 registered bugs. Whenever I present this idea I’m met with skepticism. This is seen as an utopia and not possible. My impression is that developers interpret in a way that would generate punishment when new bugs are added.

But that is not the point. The point is to embrace that we’ll always have bugs, but also aim for a process that will minimize as much as possible the amount of bugs we produce. This will make us leave our comfort zone and question our beliefs.

It’s not about “writing code that never has bugs”. It’s more about “what do we need to change in our day to day work to minimize bugs”.