- Ensuring that the bug is squashed, and the client is happy
- Managing the risk of the fix
Making sure that the bug is squashed, is the self evident part of implementing a fix. You want to ensure that the code changes that you make fix the clients issue. The issue could be that the code doesn’t work as intended, or it could be that the code does work, but it doesn’t work the way the client wants. Either way the change that you make must solve the clients issue.
What you don’t want is to implement what you believe is a fix, and then report back to the client. Only to have them test the code change to find that it doesn’t work. That just leads to embarrassment for you, and frustration for all.
The second element of implementing a fix isn’t as obvious. It’s all about managing the risk of the code change. There are a number of different types of risk. What you can’t do is yell something like ‘You’re doing it wrong!’ and then make a large number of code changes. This is because doing so creates too much risk. It also annoys the other software engineers in your vicinity who are quietly working away.
The more code changes that you make, the higher the risk that you’re introducing new bugs. The goal is implementing a fix for a bug or issue, not introducing new ones.
A high number of code changes also increases the risk of conflicts later. I don’t mean conflicts between developers, although this can happen, I mean conflicts reported by your version control software. You are running some sort of version control on your source code aren’t you?
Each change that you make has the potential to introduce code conflicts. For example if the upstream developers have fixed the bug in a different way. Or they may have made such significant changes to the code that your version control software can’t work out where in the file to make your change.
Solving conflicts in source code is not fun for anyone. Except perhaps if you’re one of those rare individuals that enjoy looking at diffs of source code and enjoy that sort of thing.
In summary, the key is to implement a fix which solves the clients issue with the minimum number of code changes. Adding code comments to indicate why you’re making the change can also be useful. Especially if you’re the person who is trying to solve a code conflict.