What is bug fixing?
In any software output there are bugs; a bug is an artefact or unexpected behaviour which varies in severity and ultimately prohibits functionality, or is at detriment to the user experience.
Not to be confused with a “new feature” which is something being introduced which was never in scope. Bugs are defects.
Bugs are usually managed through a defect management mechanism, sometimes a spreadsheet or sometimes some software. In this, they should be classified by severity; Critical, high, medium, cosmetic.
Fixing bugs is the process of accepting recorded issues and setting about implementing a solution.
How are bugs caused?
Web development bugs can be introduced in lots and lots of ways, but there are some more common entry points:
- Lacking specification, expected features missing (classified as bug)
- Information lacking in communication between parties involved
- Developer negligence
- Developer misinterpretation of feature
- Environmental (browser/OS bug)
- Feature introduced (introducing something, affects something else)
- System stress limitations (demanding too much of a server or browser in code)
Thankfully, agencies and web development houses have systems in place to review code before it goes out, and review features before they go out. Things always slip through, however!
Approaches to bug fixing
The correct way to resolve a bug is to become immersed in the problem, and the environment, establish an understanding end to end and then intercept at the point of failure. This is robust and ensures that the full picture has been assessed, and an appropriate solution selected.
There are some cases where a bug may seem very minor, from a developer perspective and a “quick fix” will be sufficient. This can be dangerous as it can introduce issues elsewhere.
Additive bug fixing - Bubble-gum style development
Bolting on fix after fix or “patches” is a bit like repairing a puncture on a bicycle tire. The overall integrity of the element has been compromised, and a patch is a solution to resolve the immediate problem. Keep patching and patching and eventually the system fails – a bit like a house of cards, or the straw that broke the camel’s back. The more patches, the greater the fragility.
Especially in legacy solutions, it’s very common to find patches everywhere. It introduces other problems too:
- Code readability is reduced
- Code extensibility is eliminated
- Documentation is fragmented or irrelevant
These all contribute to efficiency when working on that specific part of the product.
Bug fixing by patching and patching (additive bug fixing) significantly degrades the environment and is likely unreliable, amongst other problems introduced.
In some cases, it’s just best to take a hit and rewrite the system.
In all cases, one should become immersed in the environment and tackle the problem properly to reduce future complications. Whilst it can sometimes be necessary to push something out in an emergency, it’s not helping anyone.