Today as I was going through our Edoiki game code and realized I needed to get rid of some old code and replace it with better. I made some changes to bit poorly programmed part in the interface system and it caused me a headache. For some reason after making the code cleaner, the game characters stopped moving.
I (bit hastily) made some fixes that didn’t help anything. I made a few more quick changes, yet the bug remained.
Then I stopped for a moment, and took a deep breath. If I was going to fix this problem, it wouldn’t do any good to try to make it quick. Bug free programming always beats quick programming. I went through a big chunk of code line by line getting rid of some old code. I took all the time in the world, and carefully went through the lines and fixed them line by line. As I was progressing I saw clearly where the errors were and was wondering how it could have worked in the past – since there were some obvious flaws. As I fixed some bad code, making new changes was easier.
In the end, it didn’t take me many minutes to finish the fixing of that piece of code – and I thought that there were two lessons for getting rid of bugs:
Bug free programming ensures a stable base
Ensure that you kill all the bugs in the program as soon as they occur. This ensures that you have a stable base, and can build your product on top of it. I’ve practiced this guideline in the past as much as possible, and I’m pretty confident that it’s the best policy. I think killing bugs is pretty similar to building a house: better make sure that there’s a solid base before putting walls on top of it.
Killing bugs takes time
There’s no need to program in haste. I tried that, and it didn’t work out. It took me much less time to fix problems slowly. Some bugs will take more time, some less – and that’s just how it goes. Simply take your time: there’s no need to rush.