Photo by Giammarco Boscaro on Unsplash

According to the Cambridge dictionary History is “the study of or a record of past events considered together, especially events of a particular period, country, or subject”. Software applications are iterated over time, suffering changes to its structure and behavior. Each one of these iterations can be considered an event in the software application history and, this history, can be recorded in different ways either with documentation, commit history, changelogs, etc.

“Those Who Do Not Learn History Are Doomed To Repeat It.” - George Santayana

Every time I read this sentence somewhere I think about war and previous disasters that happened in the course of humanity that we don’t want to see repeated. In this blog post, I’ll present to you an analogy of the George Santayana sentence with the Software Engineering field and how the intent of the sentence can be taken to software development.

I‘m an advocate of Documentation-first methodology, believing that documentation should be as complete and rich as possible, being the source of the truth about our systems. Every question should have its answer in the documentation and if it doesn’t we have to work on it.

But we won’t talk about the formal documentation in this blogpost. We will talk about how we can record a bad event and prevent it from happening in the future. How can we ensure that a bug never happens again? Let’s dive into that!

We are not perfect and we make mistakes, period. I bet that there isn’t any Software Engineer that never deployed a bug to production, and that's ok!

Obviously no one deploys a bug to production on purpose, but it can happen and a good way to avoid it is to always implement a battery of tests alongside new implementations having the maximum code and behavior coverage. I’ll leave test coverage out of the scope of this blog post so we can focus on the bug mitigations.

When we have a bug in production we want to fix it as fast as possible but more important than fixing it fast is ensuring that this bug won’t happen again. How do we do it?

Implement specific test cases covering bug behavior.

For bug mitigation, I believe that Test-Driven Development is a great methodology having various advantages that arise when bug fixing. Over time, it has proven truly powerful in fixing the bug and ensuring that this won't happen again.

“Test-driven development (TDD) is a development technique where you must first write a test that fails before you write new functional code.”

So, we deployed our application into production and after some time we receive reports of weird behavior of our application that was affecting users. We surely have a bug that wasn’t covered in our tests, what's the first thing we should do?

Again, we need to mitigate this bug as fast as we can. But we also need to ensure that we do this mitigation with quality and, most important of all, make sure that this bug cannot happen again. This is an excellent opportunity to use Test-Driven Development.

So I start writing tests covering this bug behavior: these tests must have a clear intent of its purpose and be as expressive as possible. These tests can be tests of any kind because the important thing here is that they have quality and expressiveness.

I know that these tests I just implemented will fail and that's ok! If I had these tests before this bug would never be in production. At this point, I have one or more failing tests covering the bug we have in production. Now, I can start fixing the bug by changing the functional code.

Once I finish changing the functional code, I’ll run the tests initially implemented for this bug fix and I will be sure that the bug won’t happen again once all the tests that I initially wrote have a positive outcome.

I think that Tests are also documentation! When I don’t understand the clear intent and purpose of some code the first thing I do is to look at its tests for better understanding.

The tests implemented in the bug fix should be treated as History records. In the future, people should look at these tests and understand clearly what happened, how it was fixed, and know that these tests are ensuring that the bug won’t happen again as long as they have a positive outcome.

I cannot stress this enough, it's far more important ensuring that a bug won’t happen again that fixing it at a supersonic speed. Test-driven development in bug fixing provides a process that can help us ensure that a bug won’t happen.

When writing a test for a bug fix we are recording a piece of history regarding our codebase, this way the probability of this bug appears again in production will be minimal. Much like this blog post initial sentence if we don’t implement a specific test case for a bug we are doomed for it to appear again.

Nelson out!