Having some decade of experience in software development behind me, I had the time to accumulate a lot of mistakes. One of the recurring patterns in these failures was the ambition to solve code issues too quickly. This was especially the case when the problem was related to code that I wrote, which made me feel responsible for the situation. Naturally, I had also often think that my code couldn’t be bad and somebody must have changed it after I deliver it, but this is another story ;O)
When you detect a problem, sometimes you think that you just have to do a small change in the code to get things right. I trust myself and I want to solve the problem quickly, so I am not going to run a full regression test to check that my changes are not creating any negative side effects. This means that I can push the new code from the development repository to the production environment with limited testing. Don’t we all want this problem to be solved quickly? It worked most of the time, but sometime the solution didn’t work or just made things worse. This was mostly because I didn’t spend enough time to think about the actual issue or I had limited testing environment in development, mostly with a small set of data. This is how I start appreciating having a good integration testing environment between development and production.
The purgatory is a catholic concept of a place located between hell and heaven. People would be there in transit to make sure that they deserve to reach the paradise. I will say that we should make sure not to rush every time to production and allow our mind and our code to spend some time in purgatory. The first step is to make sure that you understand the real cause of the issue and its consequences. If you are not able to reproduce a bug, how can you make sure you are correcting it? When facing a bug, we should “take a deep breath”, taking a little bit of time to get away from this “I have to solve this quickly” feeling of urgency, but rather try to understand what the actual issue is.
When we think that we have made the right corrections, the ideal way to confirm it is to have an integration testing environment that is as similar as possible to the production environment. A place where you will find good test cases and maybe some automated testing tool to help you speed the verification process. This could be difficult if you have a special production environment with links to external systems for instance or that contains sensitive data that business people are reluctant to let the IT people explore. For this issue, anonymisation could be a good solution to provide both meaningful data and volume to the developers.
Spending some time in the purgatory often make sure that your change is a good solution and your quick fixes don’t makes the issue get worst and damage your software developer reputation. Just make sure that your code is qualified to reach the production stage.
Further reading
Coding, Fast and Slow: Developers and the Psychology of Overconfidence