Introduction
The essence of a successfully developed project is to have fewer bugs and more quality to offer in terms of features and services. It is said that bugs and the codes are separate entities, somehow like discovering a caterpillar in some lettuce you were about to eat. However, the reality is that there are no bugs, but just code which satisfies the requirements to a greater or lesser degree.
The end phase of game development is usually challenging. The dreaded crunch and the extra mile to fix bugs and add polish can be arduous for all involved. So let's talk about what we can do as game developers to save significant resources and time fixing bugs.
How to write bug-free code in Game Development
Do not repeat previous mistakes
By not repeating our past mistakes, we must develop reasoning and language to allow the team to take ownership of the problem. It must be clear that we can achieve the goal in real-time and that the responsibility lies with the specific individuals.
Observations
We firstly analyze the bug database and identify two significant cohorts we wanted to tackle:
- Bugs that took a very long time to fix, and
- Bugs that continually regressed
After grouping the bugs, we identify commonalities and root causes. This step requires a combination of programming experience and interpretation of bug description. Most of all, it required time and perseverance.
After some time, we started seeing patterns, and a subset of bugs did indeed account for a significant amount of engineering time. We then work with the engineers to find the 'fix changes.' We also compiled a list of systems, files, and lines of code related to the significant issues. Ultimately, we had a list of specific code changes to discuss with the engineering team. By doing the above processes, We have created a mapping between 'lost development time' and 'specific areas of the code.' This gives us a way to rank the value of any proposed refactoring and maintenance objectively.
Hypothesis
After making the observations, we would have concluded certain hypothesis such as:
- Specific programming patterns will be statistically more likely to cause bugs in a large software project.
- We will reduce time spent fixing bugs throughout the project if we avoid using programming patterns identified by (1).
Though in small software projects, you can get away with anything, software engineering does not matter. The code is all yours.
In a large project, the code is not yours. You will work with code you do not understand and base engineering decisions on imperfect knowledge and assumptions. Now when we talk to the rest of the team, the hypothesis turns out to be useful.
Test
An essential part of the systems architecture and technical direction for the next project would be based on avoiding identified high-risk code patterns such as-
- Overloading operators and de-normalized naming conventions.
- Pushing complexity upwards by dependency injection, callbacks, lambdas,
- Using mutex, semaphore, and other threading primitives in high-level code.
133+ registered 
