Some time this past year, a developer on my team completed some coding under schedule duress. It came as no surprise when the testers found problems with the resulting code. The trouble tickets got assigned to me. As usual, I got busy investigating the source of the trouble.When I traced the problems to their source, I found a double jeopardy of errors. The first was a classic C mistake. There were problems converting int to BOOL values. The wrong int values were chosen. We follow the standard convention of FALSE being 0 and TRUE being 1. Sure you can pass an int value when a function is expecting a BOOL. Just make sure the int has 0 or 1, and that you follow the convention.
This was not the extent of the problem though. Not all cases were being covered in the code. I know how this can happen. I have been under duress myself before. You code a special case first. When that works, you plan to go back and cover the more general case. But when you are coding to a strict or unrealistic deadline, there is never time to go back to those lose ends.
How can you prevent problems like this from happening in the first place? A naive approach would be to make sure you have time to do a good job. Sometimes that option is not a choice you can make. The alternative is to prioritize features. Then you can make sure that the most important features get implemented well. However this technique does require extra work in getting the features prioritized. And customers and bosses don’t like it when you partially deliver. I still think delivering some functionality well trumps delivering everything with a lot of bugs.
